Require the new `property_keys` method in the class that applies the TargetConfigCommand role, and use it to enforce what keys are allowed. Then just use the properties thus specified when writing the configuration file. New properties include engine, top_dir, client, plan_file, and registry. Each will get the value passed via the core option, though use of --set is preferred. Also added target, which will cause a target section to be added to the config if the target is not a URI. Target, registry, and client are all added to the engine section. The init command also injects the engine into the core --engine option, if it's not specified, since Target looks there to load the proper engine and create the proper URI. We need that for defaults. It's a bit hinky, but it works. The upshot is that the interface is now almost identical to that of the engine command. And simplify how things are written to the configuration file.
And reformat the output of `show` to be a bit less flat, so hopefully easier to read. I'm not entirely happy with the proliferation of `set-` actions in this command. I originally borrowed it from `git remote`, but starting to think it might have been better to just use a --set option like the `add` command uses. I still might go back to that...
Encapsulate that functionality as methods on ScriptConfigCommand, instead.
And stop writing out commented values for `deploy_dir`, `revert_dir`, or `verify_dir` settings. I think these settings are not commonly used, and it would start to get crowded if we also added their "reworked" variants, which will be used still less.
Oracle has a configured limit on the number of items that may appear in an IN() clause. So break it up into mutliple IN() clauses of no more than 250 items each. Oracle allows 1000 by default, but it's configurable, so let's just try to play it safe by assuming it could be as low as 200.