chore: Adopt SmithyDafnyMakefile.mk, fix nightly build

[robin-aws]

Description of changes:

Replaces nearly all of the SharedMakefile.mk with the common smithy-dafny/SmithyDafnyMakefile.mk makefile, just retaining configuration variables specific to this repo (such as the path to the smithy-dafny submodule). Uses the new features in that makefile and smithy-dafny itself to make the projects forwards-compatible with the latest Dafny nightly prerelease, and hence will fix the nightly build once merged - see here for a manual run.

Highlights of the changes:

• Apply the same workflow changes as chore: Forwards compatibility with Dafny > 4.2 (including pending 4.5) aws-cryptographic-material-providers-library#195 to use smithy-dafny to regenerate code, either to check that the output matches what's checked in (in a new separate codegen workflow) or to be compatible with newer versions of Dafny in the nightly build (in existing workflows).
  • In this case we also have to locally update the MPL submodule to the latest, so that we can pick up the forwards-compatible changes to that repo, and regenerate code transitively.
• Because the code in this repo wasn't formatted already, but applying newer smithy-dafny code generation automatically formats, all the generated code has trivial layout changes.
• Also extracted a manual patch.
• Applied a lot of explicit client downcasting to account for the change in smithy-dafny

Note that this changes the Makefile targets as a result:

• There is a default value for CODEGEN_CLI_ROOT (the smithy-dafny submodule copy) so that variable is now optional
• Targets like polymorph_codegen also now apply to dependencies transitively, just like targets such as transpile_java. Because the current state of the MPL submodule doesn't use the same smithy-dafny version or Makefile targets, this doesn't work by default, so for working locally it will generally be better to only generate for the current library via make polymorph_codegen PROJECT_DEPENDENCIES=

Open questions for reviewer:

1. Is bumping the AWSSDK.Core version slightly to make this work allowed? Or is there a more conservative way to deal with the version conflict you get when using the head of MPL?
2. Transitively regenerating code for this repo AND the MPL is quite slow, up to 10 mins. This is partially because the Makefile build targets aren't sophisticated enough to avoid rebuilding libraries in the graph. Since this is only in CI in the nightly build this doesn't seem unreasonable for now, but any concerns about the development workflow?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[seebees]

I think that the biggest changes are in the C# proj file.
We need to make sure that local development and published artifacts are both easy and safe.

[seebees]

LKTM