Migrate modules from `coder/modules` to new hub repo

[f0ssel]

Note

This issue does not cover deprecating the coder/modules repo. There is another issue open for handling that. It feels especially important that we treat that gracefully, as it's already a publicly-facing repo.

Once the new Coder Hub repo has been created, we need to migrate all existing modules from coder/modules over to the Hub repo, making sure that they follow the new directory structure. The vast majority of modules were created by Coder, so they can go under the /coder subdirectory.

The main question will be where to put some of the ancillary directories, such as all the images. One of product's goals is to get the Hub repo to the point that it's receiving 10–15 new modules/template per month, so that may cause scaling issues if we continue to put all images in a single top-level directory. An alternative could be to give each user their own image subdirectory. That could increase some file duplication, but would make contributing easier for people outside of Coder, as it limits the number of subdirectories they need to pay attention to.

Lastly, we must add new CI steps for ensuring the integrity of any module contributions. It must:

• Run all existing module tests and ensure that they pass
• Validate the structure of each module README's frontmatter (this could include making sure that any image URLs are valid)

The modules repo currently uses Bun to test everything. I think it's fine to keep that. The validation could probably be done via some simple Go files

[bcpeinhardt]

As part of this process, we need to have a new versioning strategy. In coder/modules, a release of an individual module is performed by tagging a commit with /release/some-module-name/vX.X.X>. In the new hub, we will need to include the namespace in the version tag somewhere to disambiguate modules with the same name, and add a process for producing assets from these new tags as well. For example, /release/some-namespace/some-module-name/v.X.X.X.
Since we're building from coder/modules as well to keep supported versions, we do not need to go through tagging the ported modules (since there is identical source for them in coder/modules), we simply need to be sure to tag new changes going forward.

This work should be part of #533 .