feat(json-init): add a --with-json-config=path/to/config.json flag for passing json to init

[Gankra]

This exists for hosted services that want to edit the toml mechanically.
The format is basically the json equivalent of [workspace.metadata.dist],
wrapped in a workspace field:

{
    "workspace": {
        "cargo-dist-version": "0.1.0-prerelease.2",
        "ci": ["github"],
        "installers": ["shell", "powershell"],
        "targets": ["x86_64-unknown-linux-gnu", "x86_64-apple-darwin", "x86_64-pc-windows-msvc", "aarch64-apple-darwin"]
    }
}

The given values will complete overwrite the [workspace.metadata.dist] section,
so if any fields are omitted they will be deleted from the Cargo.toml.

All the interactive logic that init supports will be ignored in this mode
(this is NOT equivalent to --yes, which runs the logic and just accepts every prompt).

generate-ci will be run afterwards as usual (disable with --no-generate-ci as usual).

fixes #278

[Gankra]

I think the fundamental question here is whether the input should overwrite the Cargo.toml completely, or if it should be a set of updates overlayed onto the current value.

Specifically this affects fields that are omitted from the json -- is that "delete the key" or "preserve the old value"?

[Gankra]

On config handling rework (stuff now generally works a bit more like oranda config):

• I use the "pattern match on the entire config to force people to update key functions" trick

  • A few functions explicitly ignore the fields with field: _ which is fine, all that matters is that when a field gets added you need to go to that function and take the moment to think if that field can be ignored too

• All fields are Options now

  • Previously we let Vecs be non-optional in more places which was a bit confusing about how they get merged
  • We do extend exactly one Vec if both workspace and package defines it -- includes
  • Theoretically this makes sense so you can have files that are included in everything and then packages still have the ability to add some stuff to it, but it's weird that it's inconsistent. It isn't an expressivity limitation, because if people don't want this behaviour they can just not use the global version at all.

• In init if a field is None we will delete it from the Cargo.toml

  • For array fields we will also do it if the array is empty
  • Now that everything is an option I need to reconsider if that makes sense

• In doing this I found a minor bug in how we handle npm-scope (fixed in third commit)

[Gankra]

landing this to unblock some further cleanup work without making this pr spiral out of control