Create a .devcontainer to make it easier to spin up and test boulder code changes

Most of the components for a dev container are already in place. The main things that we'd need for a dev container are:

1. Probably only one of each component should be configured to start, to make sure breakpoints are being hit correctly.
2. By default, none of the components should be in debug mode, but with a launch.json we should be able to attach to any running boulder process in the container with ease.

An example of a repository w/ a dev container can be found: https://github.com/satisfactorymodding/smr-api

If you clone this repo and open it vscode, vscode will (sometimes, not always for some reason) prompt you with an option to open it in a devcontainer. This container system automatically has the databases, etc all setup for the components to use.

This also means that github codespaces can actually spin up a new dev environments within seconds of pressing the "new codespaces" button.

More info: https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/

Inspect the existing component and database setup, then compare it with the linked smr-api dev container example. Define a container that starts one instance of each component without debug mode, and use launch.json to attach to running Boulder processes. Done means the repository opens in VS Code or Codespaces with its dependencies ready for testing.