Is your refactoring request related to a problem? Please describe.

As mentioned in #3236 (comment), current design of Operations struct and c8y_api::operations module presents an API that is a bit too verbose, exposes too much information to CumulocityConverter and its implementation doesn't fully account for how we use operations.

As such, this refactor aims to extract some things from CumulocityConverter into new Operations struct while providing it with a more simplified interface.

Describe the solution you'd like

The main aims of the refactor are:

Phase 1

• extract all fs operations and path building from CumulocityConverter into new operations module
• Keep track of operations for all devices inside of a single Operations struct, to eliminate complicated "find correct Operations struct for each device" logic
• Use correct data structures and expose a sane and simple API to CumulocityConverter
• Simplify the aggregation and loading of multiple Operation objects into a single Operations object

Phase 2

• Decouple "loading operation from fs" from "do substitution on topics and payloads" and "match operation and start correct command when MQTT message comes in"
• Hide the operation/template distinction from the CumulocityConverter
• Move "loading operations from fs" from c8y_api into c8y_mapper_ext

Describe alternatives you've considered

None, will update if any.

Additional context