Adds a new entry-types/merge command, which accepts two entry type handles as arguments, and merges one into the other.

Here’s how field merging is handled:

• Any field instances that map to the same custom field, and have the same handle, will be left alone in the persistent entry type.
• Any single-instance fields that exist in both entry types, but with different handles, will be left alone in the persistent entry type, and the command will note the handle change for fields of the outgoing entry type.
• Any other fields in the outgoing entry type will be added to the persistent entry type, grouped under a “Merged Fields” tab. Any handle conflicts will be resolved by incrementing the handle of the merged field, and the handle change will be noted.

Once the plan is in place and the user agrees to proceed, the command will do the following:

1. Update the persistent entry type’s field layout and save it.
2. Update any section/field usages for the outgoing entry type, to start using the persistent entry type instead (if it wasn’t already).
3. Remove the outgoing entry type.
4. Generate and run a content migration, which remaps entries of the outgoing entry type to the persistent one, and updates their content data to refer to the correct layout element UUIDs.

To propagate the change to other environments, just commit the modified project config YAML files, as well as the generated content migration, and then run craft up on other environments after pulling in the changes. Be sure to answer yes when prompted to run the pending content migration.