Support multiple service classes and auto-discovery

[mmaudet]

Context

OpenBURO currently only exposes drive services via the ServiceConnector interface. The long-term vision is to act as a unified proxy for multiple classes of services provided by backend platforms.

Proposed service classes

Beyond Drive (file storage, sharing), the system should support:

• Visio — video conferencing (create/join meetings, manage rooms)
• Mail — email access (read, send, folders)
• Communities — group spaces, forums, shared workspaces
• Additional classes as needed in the future

Design goals

Multi-service connector interface

• Define a base interface per service class (e.g. DriveConnector, VisioConnector, MailConnector, CommunityConnector)
• A single backend (e.g. Cozy-Stack) may implement several service classes
• Backend connectors declare which service classes they support

Auto-discovery

• A discovery mechanism that queries connected backends and registers available services automatically
• Expose a discovery endpoint (e.g. GET /services) that returns the list of available service classes and their instances
• Backends should be configurable (URL, credentials) and the system should probe their capabilities on startup or on demand

API structure

• Generalize the routing beyond /drive/{id}/... to something like /services/{class}/{id}/... or a similar multi-service scheme
• Keep backward compatibility with the current drive API during the transition

Out of scope (for now)

• Specific implementations of visio/mail/community connectors — this issue focuses on the architecture to support them