Hide Store and AuthorizationModel resources from user workspaces

[nexus49]

Context

The Store and AuthorizationModel resources are currently exposed via the core.platform-mesh.io APIExport, making them visible in every user workspace. These are internal technical resources that end users should not modify directly.

Goal

Restrict visibility of these resources to organizational workspaces only:

1. Create a new APIExport orgs.core.platform-mesh.io containing Store and AuthorizationModel resources
2. Add this APIExport to the default API bindings for organizational workspaces only
3. Relocate AuthorizationModel generation from provider workspaces to organizational workspaces
   • Ensure naming conventions prevent conflicts across workspaces
4. Update affected components:
   • Adjust generator/operator logic accordingly
   • Update helm-charts default configurations

Acceptance Criteria

• Store and AuthorizationModel resources are no longer visible in user workspaces
• New orgs.core.platform-mesh.io APIExport is created and bound to org workspaces
• AuthorizationModels are generated in org workspaces with conflict-safe naming
• All related operators and helm-charts are updated

[OlegErshov]

Authorization model resource should live in provider's workspace because we want to give an ability for users to modify Authorization model resource. Therefore we need to prepare a solution for avoiding Authorization model with the same name in different workspaces. This problem is described in this issue and the solution will be also proposed there #317

It was decided to hide for now only Store and IDP resources from users and this task is about hiding Store resource. For that purpose as has been described in the issue description, we would need to do this:

Platform-mesh operator:

1. Create dedicated APIExport resource system.core.platform-mesh.io
2. Create dedicated APIBinding resource system.core.platform-mesh.io
3. Add system.core.platform-mesh.io as a default one for orgs WorkspaceType
4. Remove store resource from core.platform-mesh.io APIExport and APIBinding
5. Probably update PermissionsClaims for core.platform-mesh.io APIExport and APIBinding to have Store resource in them, because otherwise it will be impossible to do CRUD operations on Store resource using MCR manager which uses core.platform-mesh.io APIExportEndpointSlice

Security-operator:

1. Use a new controller runtime manager which will reference system.core.platform-mesh.io APIExportEndpointSlice resource for Store controller
2. If reconciliation of store resource fails somewhere it's probably because of not having needed resources in
   PermissionsClaims.

Helm-charts:

1. it was decided for now use only 1 manager in 1 pod, for the system.core.platform-mesh.io manager we need to add a dedicated deployment as it's done for generator, operator, terminator, initializer