Split Plan.toml into 2 parts

[Morganamilo]

Splitting the plan file

Currently a plan file is a very large and explicit file that specifies all actions that need to be taken to go from an initial state to a releasable state. The goal of the plan is to be extremely explicit, hackable and human editable. This is so the end state is reproducible between multiple runs and any issues can be quickly fixed by tweaking the file on the fly, preventing delays in the release.

With backports becoming more and more common this initial state the plan is generated from changes more and more as time goes on. Thus is no longer makes sense to fix all details in the plan from the start.

parity publish should instead split the plan file into a 2 files.

A minimal representation that only contains necessary information (version numbers, publish = true/false, description, etc). This is the new Plan.toml file that gets committed to the release branch.

Then on each run, the plan file is expanded into a Plan.lock sort of file. This contains all of the information that used to be in Plan.toml and is calculated on each run. This intermediate representation never hits the disk but can be dumped to ensure we still have maximum control, hackability and introspection at release time.

Any information from the lock file can be put straight into the Plan file to override whatever decision parity publish would have otherwise made.

New crates

While it doesn't happen too often, sometimes new crates are backported to an old release. parity publish has no way to interact with this so the crate must be manually inserted into the plan file. This is only about 5 lines of toml but is a barrier to full automation.