CALM CLI access to CalmHub - add support for a custom API access plugin

[markscott-ms]

Description

As detailed in #1778 some users may not be able to access CalmHub from the CALM CLI without a custom plugin process doing the API access.

This could be due to authentication requirements, e.g. kerberos.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🎨 Code style/formatting changes
• ♻️ Refactoring (no functional changes)
• ⚡ Performance improvements
• ✅ Test additions or updates
• 🔧 Chore (maintenance, dependencies, CI, etc.)

Affected Components

• CLI (cli/)
• Shared (shared/)
• CALM Widgets (calm-widgets/)
• CALM Hub (calm-hub/)
• CALM Hub UI (calm-hub-ui/)
• Documentation (docs/)
• VS Code Extension (calm-plugins/vscode/)
• Dependencies
• CI/CD

Commit Message Format ✅

Testing

• I have tested my changes locally
• I have added/updated unit tests
• All existing tests pass

Checklist

• My commits follow the conventional commit format
• I have updated documentation if necessary
• I have added tests for my changes (if applicable)
• My changes follow the project's coding standards

[rocketstack-matt]

@markscott-ms how do you suggest we should be testing this to verify the change locally?

[markscott-ms]

@rocketstack-matt I can (and will) commit an example functional plugin that will work against a local dev CalmHub

[markscott-ms]

I was also drafting a documentation page for the website, mentioning the command line options, user config file, and environment variables.

Is that desirable currently, given the discussion around what a CalmHub document id is? (Currently to work with ‘calm:’ it’s a verbose API path.)

[markscott-ms]

Example usage locally:

[markscott-ms]

As discussed at #1797, get @jpgough-ms , @markscott-ms , Matt Auburn, @challamani-ms to discuss this prior to merge.