Refactor: consolidate forum parameters and confirmation parameters into a single structure.

[DFINITYManu]

What has happened here:

• Reduction of cyclic use dependencies.
• Auth stuff moved to auth.rs.
• ExecutableCommand stuff moved to ctx module, since (despite the name) it's just a vehicle to create a Ctx for commands to use. I will revise this abstraction later on -- I think it may ultimately not be necessary.
• Consolidation of everything under lib.rs instead of double importing in main.rs. Removes source of confusion and speeds up compilation.
• Confirmation options move to their own module confirm.rs to clear up confusion and the import graph.
• Forum submitter code from forum.rs moves to submitter.rs since it has dual responsibility (submit proposals and manage forum posts) so having it as a separate file adds clarity.
• Implementations of proposal executors from proposal_executors.rs move to governance.rs for the governance executor and ic_admin.rs for the ic-admin executor, breaking up an important import cycle.

One important change not in the list above:

The SubmissionParameters structure has sprung to existence to include the ForumParameters and ConfirmationModeOptions structs, and is now used when appropriate (in operations that require forum post parameters and can be affected by confirmation modes, e.g., dry run, confirm, unconditional).

These changes, together with prior changes that consolidate forum post management and proposal simulation / execution, make the code more maintainable, more explicit about what is implemented or happening and where it is, and pave the way for imbuing the Proposable types with knowledge about how to deal with the forum based on what the type of Proposable.

Noteworthy in light of the last sentence: now the Submitter type method propose() accepts a ProposalExecution (tied to a Proposable) next to a forum post type. Soon, the type of forum post can be dictated by the ProposalExecution (effectively, the Proposable) itself, which makes sense, as we already have fixed forum post types for different proposals, but this knowledge is currently (incorrectly) hardcoded in an ad-hoc manner throughout various parts of the code.

Important change: we hereby sunset the ability to pass --yes, --no and --forum-post stuff at arbitrary positions in the command line. These are now accepted only after the subcommand name. clap -- or perhaps our use of clap -- does not give us flexibility in parsing these flags anywhere in the command line. I removed error-prone code that tried to guess (with only a moderate chance of success) under certain circumstances what the user meant.

Find most current import graphs attached here:

Not all cycles have been eliminated!

[sasa-tomic]

LGTM, thanks for taking on this huge quality of life improvement!