[Feature]: Rewrite the way that OKS command arguments are mapped to `click` command arguments

Description

Currently, in drunc.controller.interface.shell_utils, the OKS FSM commands have their arguments mapped by mapping from DAL object entries to protobuf messages, with a message type for each data type (e.g. int_msg). These are handed off to the FSMCommand constructor for propagation with stateful command execution. This implementation is clunky, makes for more logic in the mapping, and means that we have to have an any_pb2.Any type in the fsm command argument validation return type. This should be generalized and simplified.

Potential impact radius

Small/Isolated

Reason for change

Removal of Any protobuf message types in command validate_and_format_fsm_arguments

Suggested implementations

message ScalarArgument {
    oneof value {
        int64 int_val = 1;
        double float_val = 2;
        string string_val = 3;
        bool bool_val = 4;
    }
}

and

message FSMCommand {
    string command_name = 1;
    map<string, ScalarArgument> arguments = 2;
}

Testing suggestions

Nothing should change, this PR will result in simpler and cleaner mapping logic.

Anything else?

No response

Start in src/drunc/controller/interface/shell_utils.py, especially validate_and_format_fsm_arguments, and review the linked FSMCommand constructor in druncschema/controller.proto. Trace how OKS FSM arguments are mapped and propagated, then replace the Any-based argument representation with the suggested ScalarArgument mapping while preserving existing behavior. Done means command validation and execution still work with the simplified representation.