Documentation and local dev enhancements

[dgivens]

This pull request introduces significant improvements to the development environment, documentation, and testing setup for the Pulumi provider for Kurrent Cloud (formerly Event Store Cloud). Key changes include the addition of a devcontainer configuration, updates to the README.md and CONTRIBUTING.md files to reflect the rebranding and new workflows, and the creation of a test project for manual validation of provider functionality.

Development Environment Enhancements:

• .devcontainer/devcontainer.json: Added a devcontainer configuration with pre-installed tools and features for Go, Python, .NET, TypeScript, Pulumi, and more. This simplifies the setup process for contributors.
• .devcontainer/setup.sh: Script to automate the installation of pulumictl, including downloading the latest release and setting up the binary.

Documentation Updates:

• README.md: Updated provider name and branding to "Kurrent Cloud," revised installation instructions, and added environment variable options for configuration. [1] [2]
• CONTRIBUTING.md: Added prerequisites, steps for building the provider, manual testing instructions, and release publishing guidelines.

Testing Setup:

• test/index.ts: Created a TypeScript-based test project to validate provider functionality, including creating a project, network, and managed cluster resources.
• test/package.json: Defined dependencies for the test project, including Pulumi and the local provider SDK.
• test/tsconfig.json: Configured TypeScript compiler options for the test project.
• test/Pulumi.yaml: Added Pulumi configuration for the test project.

Miscellaneous Changes:

• Makefile: Added cleanup commands for node_modules and nuget directories, and removed the version specification for the random Pulumi plugin. [1] [2] [3]

[rb-kurrent]

Is the idea of using setup.sh instead of a custom image that you want to pull the latest version every time? Or why not use a custom image?

[dgivens]

I didn't think it worth the effort to put that script into a whole separate custom feature. It's not likely to be very helpful to more than a small set of people. The postCreateCommand is usually either a bunch of commands strung together for repo specific setup, or in a separate script, which I prefer from a readability standpoint.

As for using a custom image, I think defeats the purpose of using devcontainer. This way, we can rebuild the devcontainer with the option to ignore the cache, and the base image and the feature layers get updated to what's current. If we used a custom image, there would be the need to keep it updated, hosting it, and so on.

[rb-kurrent]

Overall this looks pretty good to me. I kinda don't know what's going on though: what is this repo for? Is this something we maintain for internal use? Or is this something end-users would use to interact with kurrent cloud?