This commit introduces a more convenient API for managing the
private experiments.

The idea is to "lock" private data inside public objects:

```js
const { lock, unlock } = __dangerousOptInToUnstableAPIsOnlyForCoreModules(
	'<CONSENT STRING>',
	'@wordpress/blocks'
);

export const publicObject = {};
lock( __experiments, "Shh, private data!" );

publicObject
// {}

unlock( publicObject )
// "Shh, private data!"
```

The lock()/unlock() API makes it easier to implement private functions, components,
selectors, actions etc. Instead of using a separate import system, it's enough to
opt-in to the experiments and then `unlock()` the publicly available
artifact. For example:

```js
import { store } from '@wordpress/blocks';
import { useSelect } from '@wordpress/data';
import { unlock } from './experiments';

function MyComponent() {
    const hasRole = useSelect( ( select ) => (
        unlock( select( store ) ).__experimentalHasContentRoleAttribute()
    ) );

    // ...
}
```

This makes `unlock()` a drop-in replacement that does not require
reworking the current code structure around the experimental APIs.

What's also nice is that the above implementation of private selectors
(coming in a follow-up PR) is short, sweet, and fairly easy to grasp.
For comparison, an implementation based on the former register/unlock
API required quite a bit of mental gymnastics:

```js
// Package wordpress/block-editor:
export const { register, unlock } =
	__dangerousOptInToUnstableAPIsOnlyForCoreModules(
		'I know using unstable features means my plugin or theme will inevitably break on the next WordPress release.',
		'@wordpress/block-editor'
	);

const { __experimentalPrivateSelector } = unlock( dataExperiments );

import {
	__unstableSelectionHasUnmergeableBlock,
} from './store/selectors';

export const __experimentalAccessKey = register( {
	__unstableSelectionHasUnmergeableBlock: __experimentalPrivateSelector(
		store,
		__unstableSelectionHasUnmergeableBlock
	)
} );

// Package wordpress/edit-page
export const { register, unlock } =
         __dangerousOptInToUnstableAPIsOnlyForCoreModules(
                 'I know using unstable features means my plugin or theme will inevitably break on the next WordPress release.',
                 '@wordpress/block-editor'
         );

import { __experimentalAccessKey as blockEditorExperiments } from '@wordpress/block-editor';
const { __unstableSelectionHasUnmergeableBlock } = unlock(__experimentalAccessKey);
```

It also had an undesirable side-effect of requiring a separate import
and a different treatment of the `__unstableSelectionHasUnmergeableBlock()`
selector – which is to say a migration would be rather difficult.

…null values

…on arguments, and react components

releases

Introduces a private selectors APIs in `@wordpress/data` via [the new `@wordpress/experimental`](#43386 (comment)) package:

```js
// Package wordpress/block-data:
import { unlock } from '../experiments';
import { experiments as dataExperiments } from '@wordpress/data';
const { registerPrivateActionsAndSelectors } = unlock( dataExperiments );

import { store as blockEditorStore } from './store';
import { __unstableSelectionHasUnmergeableBlock } from './store/selectors';
registerPrivateActionsAndSelectors( store, {}, {
     __experimentalHasContentRoleAttribute
} );

// plain usage
unlock( registry.select( blockEditorStore ) ).getContentLockingParent();

// usage in React
useSelect( ( select ) => ( {
  parent: privateOf( select( blockEditorStore ) ).__unstableSelectionHasUnmergeableBlock();
} ) );
```

…ctors()

Co-authored-by: Ramon <ramonjd@users.noreply.github.com>

Co-authored-by: Robert Anderson <robert@noisysocks.com>

Co-authored-by: Robert Anderson <robert@noisysocks.com>

…bleAPIsOnlyForCoreModules

… returned by unlock().