Expose operational mode through individual properties

[llucax]

Using the operational mode protobuf enum as a component attribute is not very convenient. Users would need to check for multiple combinations to find out whether telemetry or control is available, plus handle the unspecified value, which should be rare but is possible.

Instead, keep the operational mode representation entirely in the protobuf conversion layer and expose it through two Component accessors that are much safer to use:

• provides_telemetry(): whether the component provides telemetry data
• accepts_control(): whether the component accepts control commands

Both raise ValueError when the operational mode is unspecified or unrecognized, so callers get an explicit failure instead of a silently wrong boolean. The mode is stored internally as two private bool | None fields that default to None (unspecified), so existing component construction sites remain unaffected.

This is a port of commit 5c729ba from frequenz-client-common, so we upgrade to it the migration should be smooth.

[shsms]

🎉

[llucax]

One thing to have is mind is that these methods raise a built-in ValueError if something is wrong, while the ones in client-common raise a specialized exception. I thought porting the whole exception hierarchy was too much, and the specialized exception is also a subclass of ValueError, so catching ValueError now should keep working in the future.