[opamp] This client needs extension points (SPIs)

OpenTelemetry Java users or vendors who create their own distros are able to wire up this opamp client. This is very useful.

The challenge comes in because opamp is a pretty generic protocol. It doesn't have opinionated minutia about what config/file formats are supported, how servers and clients should behave, or what commands even do, etc. etc. As a result, we can build clients and connect them to the server, but the semantic actions resulting from the client operations are mostly up in the air.

I'd like to propose that we introduce some SPIs that allow common/generic extension points around specific OpAMP behaviors. I suspect there ought to be several more, but the first ones that come to mind for me are:

• Identity provider - maybe something that helps to provide or discriminate/filter what items should or should not be in the identifying/non-identifying attributes.
• Effective config provider - If the client is configured to report effective config, when the server asks for it, this SPI can allow component-specific configuration providers to yield their current settings.
• Command handlers - Yup, if the opamp server sends us a command, where should it go? This SPI would allow for extensible command handling based on some criteria...probably starting with the command name or whatever.

This should allow specific, custom, and yet still undetermined use cases to be satisfied.