support multiple yaml documents in .bu file as input

Created originally in Butane by @dustymabe: https://github.com/coreos/butane/issues/481

It would be nice if we could group configuration from different types of sections together inside a yaml .bu file. This would allow for better management of the configuration (i.e. if you delete something because it's no longer needed you don't forget to delete a corresponding piece).

Here would be an example:

---
# Configure system
variant: fcos
version: 1.4.0
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-rsa AAAA...
kernel_arguments:
  should_exist:
    - mitigations=off
  should_not_exist:
    - mitigations=auto,nosmt
storage:
  files:
    - path: /etc/systemd/zram-generator.conf
      mode: 0644
      contents:
        inline: |
          # This config file enables a /dev/zram0 device with the default settings
          [zram0]
    - path: /etc/zincati/config.d/51-updates-early-monday-morning.toml
      contents:
        inline: |
          [updates]
          strategy = "periodic"
          [[updates.periodic.window]]
          days = [ "Mon" ]
          start_time = "07:00"
          length_minutes = 60
---
# Configure builder user and services
variant: fcos
version: 1.4.0
passwd:
  users:
    - name: builder
      ssh_authorized_keys:
        - ssh-rsa AAAA...
storage:
  directories:
    - path: /home/builder/.config
      user:
        name: builder
      group:
        name: builder
    - path: /home/builder/.config/systemd
      user:
        name: builder
      group:
        name: builder
    - path: /home/builder/.config/systemd/user
      user:
        name: builder
      group:
        name: builder
    - path: /home/builder/.config/systemd/user/timers.target.wants
      user:
        name: builder
      group:
        name: builder
    - path: /home/builder/.config/systemd/user/sockets.target.wants
      user:
        name: builder
      group:
        name: builder
  files:
    - path: /var/lib/systemd/linger/builder
      mode: 0644
    - path: /home/builder/.config/systemd/user/prune-container-resources.service
      mode: 0644
      user:
        name: builder
      group:
        name: builder
      contents:
        inline: |
          [Unit]
          Description=Prune Dangling and Expired Container Resources
          [Service]
          Type=oneshot
          ExecStart=podman image prune --force
          ExecStart=podman image prune --all --force --filter until=48h
          ExecStart=podman container prune --force
          ExecStart=podman volume prune --force --filter="label!=persistent"
    - path: /home/builder/.config/systemd/user/prune-container-resources.timer
      mode: 0644
      user:
        name: builder
      group:
        name: builder
      contents:
        inline: |
            [Timer]
            OnCalendar=*-*-* 05:00:00 UTC
            AccuracySec=30m
            Persistent=true
            [Install]
            WantedBy=timers.target
  links:
    - path: /home/builder/.config/systemd/user/timers.target.wants/prune-container-resources.timer
      target: /home/builder/.config/systemd/user/prune-container-resources.timer
      user:
        name: builder
      group:
        name: builder
    # enable podman socket (used by podman remote) for the user
    - path: /home/builder/.config/systemd/user/sockets.target.wants/podman.socket
      target: /usr/lib/systemd/user/podman.socket
      user:
        name: builder
      group:
        name: builder

In this case we separate "system" configuration from the builder user's configuration. We have two different passwd and storage/files sections etc..

It's just easier to reason about when you don't have to scan through unrelated things to find a corresponding piece of the puzzle.

This can be solved by using multiple .bu files and using config merging but that is a bit heavyweight.

Start by tracing the existing .bu input path and config-merging behavior, then inspect how YAML documents are parsed and validated. Use the two-document example as the acceptance case: one .bu file should accept separate configuration documents and combine them without requiring multiple files.