refactor(core)!: use class decorators for explore operators and add OperatorMetadata

[michael-johnston]

Introduce ability to decorate explore operator classes directly avoiding need for a separate function and related issues due to different sources of operator metadata.

For example with this change the operator class defines the operators name; this name is what it is registered as (ado get operators); it is used to generate the operator identifier and operation identifier field values; and it is what appears in operation resource yaml . Previously these could all be set differently.

Changes

• Extend @explore_operation to decorate classes directly. No separate function is needed (its generated automatically)
• Migrate RandomWalk and RayTune to the class-decorator pattern; delete the now-redundant functions for both
• Centralise operator metadata in a new OperatorMetadata model (moved to core/operation/config.py) as the single source of truth for each operator's name, version, type, configuration model, and implementation class.
• Rename OperatorFunctionConf → OperatorReference (deprecated alias kept for backward compatibility).
• Introduce OperatorFunction a protocol based type which can be used to type and validate operator function signatures
• Explore operations now store an OperatorReference instance in the operation resource i.e. the registered operator name rather than class name
• orchestration functions (orchestrate_general_operation, orchestrate_explore_operation, _run_operation_harness) updated to use OperatorMetadata

Breaking

The following are not supported any more

• explore operator classes without an implementation of the operator_metadata() class method: Explore operator classes must be updated to implement operator_metadata().
  - Instantiating an existing class that does not implement this method will cause TypeError: Can't instantiate abstract class OPERATOR_CLASS_NAME with abstract method operator_metadata
  - Calling this class method on the class (without instantiation) will cause NotImplementedError to be raised
  - Note: Via ado cli user will encounter one of the following two errors first if such a class exists.
• decorating functions with explore_operation decorator: This decorator can only be used on classes.
  - Existing functions decorated with @explore_operation will cause TypeError: explore_operation takes 1 positional argument but N were given to be raised when the operator registry is accessed via the cli (e.g. ado get operators, ado create op)
• Passing an operation yaml with OperatorModuleConf fields for the module field to ado create op: This was allowed but not documented anywhere as viable approach (existing only in some test files and one old example file). It's no longer allowed.
• Not supplying values for version, configuration_model or configuration_model_default to operation function decorators other than explore_operation: These fields are now required.
  • Existing uses of these decorators that don't provide values for these fields will cause TypeError: $DECORATOR_NAME takes 4 positional arguments but (number less than 4) were given to be raised when the operator registry is accessed via the cli (e.g. ado get operators, ado create op)

Deprecation

• OperatorFunctionConf: still importable as a deprecated alias for OperatorReference.
• operatorIdentifier, operationType, defaultOperationParameters, validateOperationParameters of DiscoveryOperationBase - replaced by operator_metadata

New updates addressing prior comments

[AlessandroPomponio]

I still need to look at tests and documentation, but I noticed these things

[michael-johnston]

@AlessandroPomponio last comments addressed

Changed addressed

[AlessandroPomponio]

LGTM thanks