Current xntt lock system is using State API and should be using Config API instead

Problem/Motivation

The XNTT lock system allows to lock or hide some parts of the external entity type configuration, either to make sure some parts won't be changed by the user or to limit the choices.
The first implementation of this feature was inspired from the node lock system (eg. https://api.drupal.org/api/drupal/core%21modules%21node%21src%21Entity%2...) that was relying on the state API. However, restricting access to some part of the XNTT type configuration is something that should remain in config and be exportable from one site to another, which is not the case with the state API.

Steps to reproduce

Use xntt_example_d7import module, export and import the config on another site: the restrictions are gone.

Proposed resolution

Instead of using the state API, the external entity type should include properties to manage the current lock system.

Remaining tasks

Replace the use of the state API by XNTT type properties that can be exported into config files.

User interface changes

None.

API changes

The locking system will not be managed in "module.install" files anymore.
The state "external_entities.type.locked" will be removed.
A new update hook should be able to transfer what was stored in the state API into XNTT type configs.

Data model changes

The XNTT type will include new properties to support the locking system.