Introduce soft deleted list option for soft deletable entities

[strailov]

Add soft_deleted_mode query parameter to listing REST endpoints

Summary

Introduces a soft_deleted_mode filter parameter to all soft-deletable entity listing endpoints, allowing API consumers to query soft-deleted entities that were previously hidden from listing results.

Motivation

Soft-deleted entities (Distribution Sets, Software Modules, their Types, and Rollouts) were previously only accessible by direct ID lookup. There was no way to list or search them via the REST API, making it difficult for UI and integrations to display or manage deleted resources.

Changes

New API contract:

• SoftDeletedMode enum (only_soft_deleted, exclude_not_soft_deleted, include_soft_deleted) with safe fromValue() parsing
• SoftDeletableRepositoryManagement interface extending RepositoryManagement with findAll(SoftDeletedMode, Pageable) and findByRsql(String, SoftDeletedMode, Pageable)
• count(SoftDeletedMode) added to RepositoryManagement with fallback for non-soft-deletable entities

Affected REST endpoints:

• GET /rest/v1/distributionsets
• GET /rest/v1/distributionsettypes
• GET /rest/v1/softwaremodules
• GET /rest/v1/softwaremoduletypes
• GET /rest/v1/rollouts (compact mode only; full mode intentionally excluded)

Mutation guards:

• update, lock, unlock, invalidate, assignTag, unassignTag now reject operations on soft-deleted entities with DeletedException

Implementations:

• JpaDistributionSetManagement — refactored findByRsql to support deleted filter while preserving legacy complete field handling
• JpaSoftwareModuleManagement, JpaSoftwareModuleTypeManagement, JpaDistributionSetTypeManagement — added findAll/findByRsql with soft-delete filtering and update guards
• JpaRolloutManagement — added findAll/findByRsql with SoftDeletedFilter
• Chosen that approach instead of introducing this logic in AbstractJpaRepositoryManagement due to that some entities are not soft-deletable by definition. So the current approach may have some duplications with findAll or findByRsql implementations but seems with more clear architecture approach and distinguish those entities.
• Soft-delete mutation guards - Soft-deleted entities must reject mutation operations (like Rollout already does). Users can stumble into "Entity exists" errors due to unique key constraint violations on soft-deleted entities they cannot see. Here I rejected the approach with intermediate class due to AbstractJpaRepositoryManagement → AbstractJpaRepositoryWithMetadataManagement - Would need two variants (with/without metadata) or force unrelated coupling. Not worth the complexity. Decided to override the updates for each entity which is easy to review, no risk for other entities and straightforward .
• Reject all for bulk updates - to be still considered ...