feat!: add the ability to deprecate a prebuilt provider

[xiehan]

While this is not technically a breaking change, I want to force this to be released as v0.5.0 so that it's easier to roll back to v0.4.x in case there are any issues with this in testing.

At its core, this change is relatively simple: it introduces an isDeprecated flag on the config for providers built using this project that defaults to falsy. All the new behavior is controlled by that flag, so it should mean that this is safe to merge, as no new functionality will be triggered for any providers unless/until they are marked as deprecated.

(There technically is also a new option called deprecationDate -- in practice I don't intend to use that and will just rely on the build date; however, in order to not have the test snapshots be regenerated every day with a new date, I needed a way to force-override the new Date() behavior.)

If the isDeprecated flag is set to true, then the following happens:

• The "should-release" logic is removed because we want to force one final release
• The "provider upgrade" and "upgrade-main" workflows are removed to avoid any accidental updates before the repo is archived
• The text in the README will have a disclaimer about the deprecated status of this package added to it, and the sections about Versioning and Contributing that are no longer relevant will be removed
  • Thanks to feat: publish a top-level README in Go repositories #371, these README changes will show up in the Go repository as well
• The Go package will be marked as deprecated -- see here for how this is done in Go
• The NPM package will be marked as deprecated after the next and final release

PyPi and Maven unfortunately don't support deprecating an entire package. NuGet does, but there's no API/CLI for it; it has to be done via the web UI.

While it's huge, looking at the test snapshot file might be the best way to visualize the changes. The first example in that file is of a provider that's been marked as deprecated -- in particular, scrolling down to the README will demonstrate what that looks like for a deprecated provider. The other snapshots demonstrate that there shouldn't be any unintentional outcomes for providers that have not been explicitly marked as deprecated.

Side note: while I was working on this I realized that hashicorp/terraform-cdk#2575 is very important now because we link to https://cdk.tf/imports a lot to explain how to manually generate bindings, but some of the examples there incorrectly use the prebuilt providers, so I have added that issue to our next release.

[github-actions]

I'm going to lock this pull request because it has been closed for at least 7 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue so we can investigate further.