feat(governance): New proposal type: CreateCanisterAndInstallCode.

[daniel-wong-dfinity-org]

This is behind a flag, which per usual, is off in production.

This includes changes to .did, .proto, as well as actual executable implementation, including validation.

Prior Work

This new proposal type overlaps a bit with the existing NnsCanisterInstall proposal type. This differs in a couple of key ways:

1. The created canister can live in other subnets.
2. The created canister is NOT designated as an NNS canister (in Registry).

Implementation

This is a direct proposal action. This is because we implement validation (which would require Decode if this were instead done as an NnsFunction).

This follows the usual pattern of adding a new .rs file to the proposals dir, dedicated to the new proposal type. Within that file we have various impl blocks related including ones for various traits.

Calls a new method of the Root canister, aptly named create_canister_and_install_code. See "References". As usual, Root does the real work.

Un-nested CanisterSettings from within UpdateCanisterSettings so that it can be shared with CreateCanisterAndInstallCode.

A large chunk of the changes here are mechanical type conversions.

Testing

Not yet tested, but since this is behind a flag, it should be fine for this code to be deployed (and in the master branch).

References

👈 Previous PR

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP