Support for cascading configurations

[epage]

The idea being that we merge the configs from the following locations

• CLI flags
• manifest path's directory
• either every parent directory or the workspace root
• home
• env variables (where does this fall in precedent order?)
• defaults

Use cases

• Centralize most release knowledge with overrides per repo in a mono repo
• Allow some settings to be left up to the user

Questions

• Should replacement file paths be relative to the manifest path or the release config?

Possible implementation

• Mergable struct
  • Switch all config settings to Option<_>
  • Have a merge function
  • Have member functions that unwrap_or the field's default
  • Have a function that creates the struct with all defaults applied
• Cascading struct
  • Create a struct ConfigSource of Option<&_>
  • Have conversions from ConfigFile, ConfigArgs etc to ConfigSource
  • Create a Config struct that orders all of the potential sources
• Cascading trait
• Mergble trait
  • Config struct with non-Option members
  • Config::from_sources(&[&dyn ConfigSource])
• Load it all into a hash map, perform hash map merges, and then move to the current config struct. The downside is this defers error reporting, making it so you can't report which file caused the problem

[sunng87]

Currently we support the config source from:

• cli options: top priority
• release.toml in project root
• package.metadata.release section in Cargo.toml
• .release.toml under HOME: used when neither release.toml nor package.metadata.release configured

As we have workspace supported, it makes sense to support release.toml or meradata.release from workspace parent or root.

Should replacement file paths be relative to the manifest path or the release config?

I think it should be relative to where it configured.

Have a merge function

Good catch because items in replacement should be concat together instead of overwrited.

I'm +1 for the first implementation proposal. It may also simplify the big section in main.rs

[epage]

/// 2. $(pwd)/Cargo.toml package.metadata.release (with deprecation warning)

I'm not seeing this deprecation warning.