Improve Capabilities implementation in new platform

[pgayvallet]

This is a follow-up of #45393

the Capabilities feature has been migrated to NP. However, there are some improvements that should still be done:

• extract the client-side CapabilitiesService from application and move it as a first class service.

Two reasons for this: 1/ this is consistent with server-side. and 2/ capabilities are not really directly related to applications, so it really makes sense to move the capabilities service from applications.

• remove the dual anon/authenticated routes and use a single route instead

See #51438 (comment)

• rename navLinks to applications

navLinks is the old, legacy term that was only representing the chrome navigation links. In new platform, this is superseeded by our Application concept. We need to replace Capabilities.navLinks to Capabilities.application and perform the associated changes, that are mainly in security and space's CapabilitiesSwitchers

• restrict plugin access to their own capabilities

Currently capabilities are exposed globally to every plugin. We should probably restrict capabilities accessible to each plugin to only the one they registered. This could be done by keeping track of which plugin registered which capabilities.

• find a way to enforce capabilities types (?)

Currently the Capabilities type is merely a Record of Record<string, boolean>. It would be a big plus to enforce some proper typing around this. I don't think we can strongly type them in core, but at least a typed getter as we do for config would be great.

Something like core.application.capabilities.get<MyPluginCapabilities>()

Due to a lot of usage of capabilities in legacy JS code, that should probably only be addressed post 8.0 when all plugins actually migrated and when we have typescript to back us up for these changes that are going to impact a lot of files.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[kobelb]

Currently capabilities are exposed globally to every plugin. We should probably restrict capabilities accessible to each plugin to only the one they registered. This could be done by keeping track of which plugin registered which capabilities.

We'll have to think through how this works when features are integrated with other features. For example, the Dashboard application currently looks to determine whether or not the Visualize application has the "edit" capability before rendering the "Create visualization" elements from within Dashboards.

[pgayvallet]

I was expecting that kind of usages. To be honest the two last points are more questions than convictions.

However if we do want to restrict them, the two options I see would be:

• Plugins can see capabilities of the plugins they depends on (both required and optional dependencies)
• Plugins that have capabilities that needs to be consumed by other plugins should expose the necessary APIs in their setup/start contract.