Allow for unserialized behavior config

Problem/Motivation

Currently, the Entity Type Behaviors module stores all behavior configuration from plugin forms as PHP-serialized data. It does the job, but is pretty messy to read compared to Drupal's standard serialization to YML.

I would like to be able to store 'config' data using Drupal's general config serialization instead.

Proposed resolution

An alternate to the entity_type_behaviors.settings_base schema will need to be provided, called something else such as "entity_type_behaviors.settings_base_unserialized", which types the config key as a mapping instead of as text.

While keeping the default serialize/unserialize handling, provide alternate handling that does not serialize, and allow individual plugins to opt-in to forgoing serialization. Ideally this would be done by defining the config schema for that specific plugin, and setting the type to the new non-serialized base. I don't know how easy this is to check though, not too familiar with looking up schema programmatically.

It definitely has to be opt-in, since we don't want to break existing plugins for this module.

Remaining tasks

The module already provides base/default schema for plugin configuration that can be extended for custom schemas, so we're good there.

#3279519 has already fixed an issue where the default config schema was not associated to the entity type behavior config, which would otherwise be a prerequisite.

Remaining steps to take to add this feature:

• Create an alternate config base object called something like "entity_type_behaviors.settings_base_unserialized" with the config field defined as a mapping.
• In Config/BehaviorConfigFactory, make the calls to serialize() and unserialize() in saveBehaviors() and getConfigDataForEntityTypeAndBundle() conditional. The condition should check on config schema. The closest check would be, if the schema for the given behavior key has the property "config" defined, and it is defined as a non-string, skip the serialization step. If it's not possible to check on the details of individual properties, then maybe a check by name is possible: any schema whose "parent" type is the new unserialized schema type should skip serialization. Worst case, if it is somehow not possible to check on the config schema at all, there may need to be a separate step in opt-ing in - maybe it would be an annotation value instead.