Replace language-specific config files with a top-level key-value config system

[Walter-Reactor]

Broken out from a discussion in #767

Languages like Kotlin & DemoGen currently use conf.toml files for certain top-level configuration attributes during codegen.
Ideally, we'd be able to specify language-binding specific top-level attributes, like python module name or kotlin domain, in the actual source rather than relying on separate toml files.

Exact syntax TBD. This may be complicated since a crate will usually have multiple implementation files (as in the feature_tests example).
The ideal solution would be to allow specifying one and only one DiplomatConfig object per crate, then append multiple key/value pairs to it.

rough sketch:

lib.rs

...
Diplomat::config()
  .add("python", "module", "mymodule")
  .add("kotlin", "lib_name", "kt.mymodule");
  .add("cpp", "min_version", "20");

[Manishearth]

The way I see it is that it can work similarly to the attribute system, where there are some common config keys (e.g. lib_name) that are shared between backends that care, and there can be backend-specific stuff too if we ever want.

I'd want the config to be specifiable from multiple places

So, something like

lib_name = "mymodule"

[kotlin]
domain = "foo.bar"
lib_name = "mymodule" # can override root keys

[cpp]
min_version = 20

OR

diplomat-tool kotlin --config lib_name=mymodule --config cpp.min_version=20

OR

// lib.rs

#[diplomat::config(lib_name = foo, cpp.min_version = 20)]
struct Dummy;

And of course we can have a programmatic API for this too.

In general I do not want Diplomat to ever have to parse Rust expressions, so having the config be specified in lib.rs as something other than attributes is not great.

Proposal for steps:

• Design a shared Config type with the right entries and structure, so that it is easily extended. Probably something like struct Config { shared: SharedConfig, cpp: CppConfig, ...}.
• Have it deserialize from toml to retain current functionality
• Have an attribute based API for specifying config
• Add a CLI API for config

Thoughts?

[ambiguousname]

Per discussion in #661, I'm happy to go ahead with adding the config system described above, and will be self-assigning to this task.

If anyone else has thoughts/suggestions, let me know!

[Manishearth]

I think the priority is for there to be some structured system, and per-backend overrides can happen later if it's not simple to do.