[META] Consider splitting the AI Automators module

Problem/Motivation

The AI Automators module is a very powerful system doing an awful lot, akin to the AI module itself:

1. An AI Automators plugin that provides a system for interacting with an external AI in a variety of ways and processing the returned values in different ways.
2. A system that allows AI Automators to be linked to fields and processed on node save.
3. An AI Automator Chain entity that allows multiple AI Automators to be run in sequence from a single input and give a processed output in return.
4. Integration between AI Automator Chains and the AI CKEditor Integration module.

Due to it trying to be all things to all people in a single module, it does not list all of its dependencies (field_ui is required to link AI Automators to fields; ai_ckeditor is required to use AI Automator Chains outside of custom code) because not all users will be using that specific functionality. Whilst there are work arounds in place to warn users and prevent the UX getting too confusing, there is still a lot of database tables and code being used for functionality that at least some of its users won't want.

Proposed resolution

In order to give users as much control over what is added to their site - and to reflect the extreme flexibility of the AI Automators core functionality - this module should be split into its own project. It should be split into multiple (sub-)modules, each responsible for one part of the functionality:

1. AI Automators (Core): providing the plugin system itself.
2. AI Automators Fields: providing the code to run automators set against fields (possibly could be part of the core module)
3. AI Automators UI: Providing the UI allowing users to set AI Automators on entity fields, declaring its dependency on Field UI.
4. AI Automator Chains: Providing the Automator Chains entity and related functionality.
5. AI Automator CKEditor Integration: Providing the link between AI Automator Chains and the AI CKEditor

In this way, users who want the current functionality can enable all modules, but users who only want a specific part of the functionality can enable a smaller sub-section of modules. This will give their sites a smaller footprint, and allow each module to properly declare its dependencies to assist with the installation process.