refactor: Refine scaffolding for maintenance actions (DEV-3532)

[BalduinLandolt]

Pull Request Checklist

Task Description/Number

This PR is mostly strictly refactoring: Moving code to separate file, etc. The most significant changes are:

• removal of an unused dependency (PredicateObjectMapper) and its transitive dependencies
• introducing a trait for maintenance actions (let me know if you find that useful at all!)
• using the actual string values of the path variables for the different maintenance actions endpoints as examples in the OpenAPI docs.

PR Type

• build/chore: maintenance tasks (no production code change)
• docs: documentation changes (no production code change)
• feat: represents new features
• fix: represents bug fixes
• perf: performance improvements
• refactor: represents production code refactoring
• test: adding or refactoring tests (no production code change)
• deprecated: Deprecation warning (ideally referencing a migration guide)

Basic requirements for bug fixes and features

• Tests for the changes have been added
• Docs have been added / updated

Does this PR introduce a breaking change?

• Yes

Does this PR change client-test-data?

• Yes

[linear]

DEV-3532 Add template for DB migrations to DSP-API for discussion

[seakayone]

idea: If we would type the params as A you could use Any for A to indicate that no params are necessary. This saves us from double checking in the execute method if params is a Some.

[BalduinLandolt]

done in a26c378, thanks for the hint, looks much nicer.

We can then type it as Any or Nothing, both seem to work.
The only downside is that I cannot provide a default argument anymore, so instead of calling FooAction(null).execute(), I have to do FooAction.execute(()). That's slightly less intuitive, but I think it's ok.
One option to get this to work might be to have a trait NoParamMaintenanceAction that constraints the type... but I don't think it's worth it.