Build a standalone symposium executable

[rschmitt]

What does this PR do?

This change adds a symposium executable that is functionally identical to cargo-agents, so that other ecosystems can use Symposium without apparently introducing a cargo dependency.

The two binaries have distinct entry points in src/bin, partially to avoid a warning from Cargo and partially because a shared entry point wouldn't deduplicate the extra build work anyway.

Disclosure questions

AI disclosure.

• The AI tool authored large parts of the code

Questions for reviewers.

1. Is this really the best way to install the same tool under two names, with all that entails (compilation times, artifact size, etc)?

[Fluzko]

Hey @rschmitt, glad you got interested in Symposium 🙌🏽
So, I think you're trying to tackle two big things here.
Big obvious one, is making it installable without being a cargo dependency, which leads to the second part, being usable by other ecosystems, which nowadays, requires much more work and thinking.
I don't see it working in other environments with these changes, basically because as a starting point it runs cargo metadata to check if there're Symposium plugins worth to install. This doesn't work at all.

If you'd like to chase the use Symposium in other ecosystems I'd open an issue and discuss about the idea and details there, and finally reach to an RFD.

[gmemuriuki]

100% agree with @Fluzko , take a look here https://symposium.dev/rfds/TEMPLATE/index.html and write an RFD for this feature first. @rschmitt.

We want eventually to be able to support even other ecosystems, and the RFD design could a really good first step towards that. https://symposium.dev/blog/announcing-symposium.html#whats-next

[gmemuriuki]

Also, you can drop in the zulip and start a chat there for this: https://symposium-dev.zulipchat.com/