Enhance module settings to allow for module takeover

## Feature Description

While the concept of module ownership has been in Site Kit for quite some time, its utility has been mostly limited to informational purposes (e.g. who to contact regarding access problems). With dashboard sharing, ownership became the mechanism by which sharing was possible, and introduced the concept of module recovery – the ability for another admin with access to a shared module's entity to take ownership of the module in order to restore data sharing if the module's owner were to lose access.

Due to the increased importance of module ownership, especially around transfer of ownership in multi-admin environments, additional safeguards were added in the module settings interfaces to prevent a user from taking ownership unless they had access to the current module's entity by preventing the owned connection settings from being editable. See https://github.com/google/site-kit-wp/issues/4825

This issue is about introducing a way around these very limitations, without which require another admin who does not have access to disconnect and re-setup a module entirely. This can be likened to the owned settings being in a locked state if the user does not have access, but providing a way for an admin to unlock them anyways and make changes anyways, but in a deliberate way.

Another case to consider here is where it may be desirable to take over a module without making any changes to the connection, e.g. to enable sharing. One use-case here is similar to module recovery in a way, but for an unshared module.

---------------

_Do not alter or remove anything below. The following sections will be managed by moderators only._

## Acceptance criteria

* For modules with service entities that require access to manage (e.g. Analytics), for non-module owner admins who can encounter this blocking state, it should be possible to "unlock" the connection settings, via an explicit action (i.e. "I know what I'm doing")
* Once unlocked, the connection settings should be manageable as if the current user was the module owner
* This should require the user to change the connection to one that they had access to in order to save the settings (the precondition here implies the user does not have access)
* Updates in the interface regarding sharing implications should continue to be displayed in this scenario when the connection is changed if the module is shared
* Canceling out of the settings edit view before saving should continue rollback any changes including the locked state of protected connection settings

## Implementation Brief

*

### Test Coverage

*

## QA Brief

*

## Changelog entry

*