[feature] Support for Out-of-Tree GUAC Backends

[robert-cronin]

Describe the solution you'd like This proposal aims to allow GUAC backends to be developed and maintained out-of-tree, similar to how Kubernetes transitioned its cloud providers. This approach could be the first step towards eventually migrating some or all backends out-of-tree, however this proposal is specifically targeting the ability to register new out-of-tree backends.

A couple of thoughts:

• By supporting out-of-tree backends, they can be updated and released independently of the core GUAC releases. This allows for faster iteration on backend-specific features and bug fixes without impacting the core. A good historical analogy might be the migration of the cloud providers for Kubernetes out-of-tree.
• Decoupling reduces the complexity of the GUAC core codebase, making it easier to maintain and scale. It also isolates issues to specific backends without affecting the main application.
• Allowing backends to be out-of-tree lowers the barrier for external contributors to develop and maintain new backends, fostering a more vibrant ecosystem around GUAC.

I think there are two possible approaches to achieve this:

1. Expose Backend Methods for External Use by making backend registration and initialization methods in cmd/guacgql publicly accessible. This would allow external backends to integrate by importing those methods.
2. Modify GUAC to load backends at runtime via a plugin interface or service discovery.

I'd be more than happy to drive the work and put up an initial PR. I think # 1 should be the shortest path with the least change to codebase. Any feedback or suggestions would be greatly appreciated!

Describe alternatives you've considered

• I guess the alternative would be for out-of-tree backend to maintain a fork of the guac codebase.

Additional context N/A