yaml merge key handling

[clux]

have it working under an optional flag that only works with yaml input.

not sure if this is enough to warrant a different input enum, or if it just needs another flag (that doesn't clash with jq) that only works in the yaml mode..

maybe we should just always do this for yaml tbh - it makes no sense to pass through tags to jq.

[clux]

three options here:

make this mandatory for yaml

PRO: always merge on yaml, less user confusion
CON:

• not sure if there are errors this can cause on non YAML 1.2 users (apply_merge can fail)
• people could genuinely use << as a key as it's not part of the standard

make it opt -in as a flag

PRO: two different ways to parse yaml, one cheap, one more expensive. we support both.
CON:

• flag is yaml centric and must be tied to input

make it opt-in as an input format

PRO: more cleanly separates the the distinction, and no extra flag that only works with yaml needed
CON:

• unclear what to name it (yaml vs YAML, or bring in yaml standard version names)
• awkward binary usage yaml is implied by yq binary name and alias tq=yq -i=toml

kind of leaning to keeping it as an opt-in flag for now.

[clux]

decided on -x for now to avoid taking -m which i feel could be useful if we want to backtrack on the multidoc default we have set

[clux]

ok tried three different variants on documents with merge and it's all weird AF if you don't apply merges (we are already singleton mapping so it's really odd to not apply merges).

here's what the circle test looks like with partial expanding (singleton but no apply_merge):

# yq -y --partial-expand .workflows test/circle.yaml
my_flow:
  jobs:
  - build:
      filters:
        <<:
          tags:
            only: /.*/
  - release:
      filters:
        <<:
          branches:
            ignore: /.*/
          tags:
            only: /v[0-9]+(\.[0-9]+)*/

which incidentally is also how it looks even without singleton mapping...

with both it looks like this:

$ yq -y .workflows test/circle.yml
my_flow:
  jobs:
  - build:
      filters:
        tags:
          only: /.*/
  - release:
      filters:
        branches:
          ignore: /.*/
        tags:
          only: /v[0-9]+(\.[0-9]+)*/

so have left full expansion the only sensible behaviour