RFC: tweak the way customization are done

This is a complex RFC, sorry, I can try to break it into smaller
discussion points but it's tricky. Let me try to break it down:

1. Simplify the way customization inputs are read. it seems we
are already doing yaml everywhere so let's just read an input
file (just like a blueprint today with composer). Passing the
values via `-Ckey=value` seems cumbersome and we (or our users)
will run into quoting issues. Or is there a benefit of doing it
that I'm missing? Note that we could simply support `-C -` to
read the data from stdin if scriptability is the goal.

2. Describe why `otk.define` and `otk.customization` are distinct.
I don't have a good answer here but I think it's quite important
that we have clarify why we need a different mechanism. On the
surface it looks like another way to define a variable (which we
can do today) and some `if/default` which we could add to
`otk.define`d variables (fwiw, I'm not fully clear why we need
two but my gut-feeling is that it's the right approach so having
it slightly more formal/well defined "why" would be nice).

3. Tweak how the customizations recieve their data. The existing
strawman was `this.` which is a reasonable choice, this commit
uses `$customizationname` now directly, I'm not sure what is the
best but it looks nice in the examples so maybe it's a reasonable
starting point.

4. Tweak the example - this is a tricky one. So far in our actual
examples we have very simple cases (hostname, timezone) etc which
are just strings (and which we could support without a `otk.customization`
by just defining a default `otk.define.hostname` and then letting
the user `override` it via a `otk.include "user-customizations"`.
When trying to build a complex example with the `user` customization
or the `container` customization I ran into the issue that both
have multiple entries so writing them directly in the yaml is
tricky. It seems `users` would become a `otk.external.users` so
that we can use python to generate the required stages. But I
think it would be good to find examples of complex customizations
so that we nail the concept a bit more down.

doc/03-omnifest/01-directive.md

@@ -196,26 +196,66 @@ otk.meta.kiwi:
 
 ## `otk.customization`
 
+A `otk.customization` is distinct from a `otk.define` because:
+- End-users will supply them
+- ?
+
 Customizations are conditional blocks that receive separate input through
-`otk compile -Cname=data`, a customization is considered to be active when it
-is passed data. If a customization is passed multiple times then the `defined`
-block is repeated multiple times, once for each input.
+a `customization` file `otk compile -C customizations.yaml` that contains a
+map of customization settings in yaml format, e.g.
+```yaml
+hostname = "lala"
+
+[[user]]
+name = "alice"
+password = "$5$xx$aabbccddeeffgghhiijj"  # notsecret
+key = "ssh-rsa AAA ... [email protected]"
+groups = ["wheel"]
+```
 
-Expects a `map` for its value which contains an `if-set` key. The `default` key
-is optional. If a `default` key is not passed and the customization is inactive
-then the customization block is effectively a no-op and will be removed from the
-tree. The values of `default` and `if-set` can be of any type.
+In the `otk` files a customization is expected to be a `map` for its
+value which contains an `if-set` key. The `default` key is
+optional. If a `default` key is not passed and the customization is
+inactive then the customization block is effectively a no-op and will
+be removed from the tree. The values of `default` and `if-set` can be
+of any type. In `if-set` the value of the customization can be accessed
+as if it was a `otk.define` defined variable with the same name as the
+customization.
 
+Simple example for a hostname customization:
 ```yaml
-otk.customization.name:
+otk.customization.hostname:
   default:
-    - type: org.osbuild.stage
-      options: none
+    hostname: "localhost.localdomain"
   if-set:
-    - type: org.osbuild.stage
-      options: ${this.data}  # it's not going to be `this`
-    - type: org.osbuild.stage
-      options: ${this.data}  # it's not going to be `this`
+    hostname: ${hostname}
+```
+and the matching customization file:
+```yaml
+hostname = "lala"
+```
+
+Complex example for a customization could include adding stages but
+we have no use-case for this yet (TBD: do it with users which requires
+a loop because there can be many users):
+```yaml
+otk.customization.somename:
+  default:
+    - type: org.osbuild.stage1
+        options: some-default
+  if-set:
+    - type: org.osbuild.stage1
+      options: ${somename.stage1.data1}
+    - type: org.osbuild.stage2
+      options: ${somename.stage2.data2}
+```
+and the matching customization file:
+```yaml
+somename:
+  stage1:
+    data1: foo
+  stage2:
+    data2: bar
 ```
 
 ## `otk.external`

example/fedora/osbuild/stage/hostname.yaml

@@ -5,4 +5,4 @@ options:
     default:
       hostname: localhost.localdomain
     if-set:
-      language: localhost.localdomain
+      hostname: ${hostname}

example/fedora/osbuild/stage/locale.yaml

@@ -5,4 +5,4 @@ options:
     default:
       language: en_US
     if-set:
-      language: en_US
+      language: ${locale}

example/fedora/osbuild/stage/timezone.yaml

@@ -5,4 +5,4 @@ options:
     default:
       zone: UTC
     if-set:
-      zone: UTC
+      zone: ${timezone}