Feature/379 support active mq artemis

[anoordover]

**Closes #379 **

PR Checklist

• Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
• Based off latest main branch of toolkit
• PR doesn't include merge commits (always rebase on top of our main, if needed)
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Contains NO breaking changes
• Every new API (including internal ones) has full XML docs
• Code follows all style conventions

Other information

Copilot reviewed 6 out of 11 changed files in this pull request and generated no comments.

Files not reviewed (5)

• examples/activemq/CommunityToolkit.Aspire.Hosting.ActiveMQ.MassTransit/CommunityToolkit.Aspire.Hosting.ActiveMQ.MassTransit.http: Language not supported
• src/CommunityToolkit.Aspire.Hosting.ActiveMQ/PublicAPI.Shipped.txt: Language not supported
• src/CommunityToolkit.Aspire.Hosting.ActiveMQ/ActiveMQContainerImageTags.cs: Evaluated as low risk
• src/CommunityToolkit.Aspire.Hosting.ActiveMQ/ActiveMQServerResource.cs: Evaluated as low risk
• src/CommunityToolkit.Aspire.Hosting.ActiveMQ/ActiveMQBuilderExtensions.cs: Evaluated as low risk

[aaronpowell]

My primary question with the design is whether we want to make it more obvious from the types what kind of ActiveMQ resource you're working with.

So rather than having a single ActiveMQServerResource, we would have ActiveMQServerResource (aka - Classic) and ActiveMQArtemisServerResource which either inherits from ActiveMQServerResource or is its own ContainreResource implementation.

Then we would have methods like AddActiveMQ that exists today and a new AddActiveMQArtemis method that creates an Artemis implementation, which means that it's very clear from the code what server implementation is in use.