Move out all provider modules to contrib modules

This works, but:

1. Needs further testing as we need to make sure we get this right
2. Needs update hooks in the external modules just like the one added to Pinecone: https://www.drupal.org/project/ai_vdb_provider_pinecone/issues/3483565
3. Needs to have further deletions of all moved modules
4. Needs to have further deletions from composer.json
5. Needs to have further deletions in docs folder

So sort of needs work/needs review dual state.

The files to look at to review:

1. ai.install -> in particular see the Scenarios bit
2. ai.module -> prevents accidental uninstall; see the comments, the user could really want to uninstall and not switch, so there is a route

I put detailed comments in both of those there.

The deletions add noise to the MR, but are needed for tests to pass since composer dependency gets removed (in example of pinecone so far).

Temporary alternative:
One alternative has been suggested of setting all submodule new external module versions as composer dependencies. That kicks the can down the road as it doesn't force the switchover, so still update hook is needed so AI core module can enforce stopping usage of the old modules and let us safely delete them from here.

It also means that sites then get a lot more top-level modules temporarily. Same amount of code as is of course, but some users may be unhappy with that.

So I think we should aim to try to get it working well with a full removal.

What I tried
I tried a couple runs at this with pinecone to test:

1. Enabled external pinecone module -> old one successfully uninstalled and config copied over: this is the simplest case
2. Ran updb without any knowledge of new external module -> ai core told me to composer require the external pinecone module.
3. Run updb with composer require of new external module -> ai core module triggered the install file of pinecone which then did (1)

Side note: I checked with Marcus in slack first before working on branch, to check he hadn't started since its assigned to him.

Not 100% sure if we need to leave placeholder info yml files in place for a bit...
e.g.

lifecycle: deprecated
lifecycle_link: "https://www.drupal.org/project/ai/issues/3483356"

Added back in info.yml
Yep, its not possible to run e.g. `drush cr` without it because of the module name change. I think this must be why Drupal Core forces you update to the latest within Major version. I added back in the info.yml file.

Updates from AI alpha 8 to further jump when deprecated modules completely removed
There is still a risk regardless of scenario that a user is on e.g. alpha8 or earlier, and doesn't update e.g. for a few modules to some point when we have removed the deprecated submodules though. In that case, we could either decide:

1. Its alpha, its okay - the edge case will come to issue queue and find similar issue
2. We increase semver to 2x, so user's will have to more consciously do it

(2) is probably the proper way and matches Core movement of modules from Core to contrib I think, but not a hill I'll die over...

Hook requirements additional helper
I additionally added this morning hook_requirements as well, which happens even earlier than updb. Still the user can skip this, so I left that particular scenario in the updb hook.

We are doing some issue management housekeeping and adding/removing components.

The "Providers" component will be removed because providers have been moved into their own projects, so this issue is being moved to "AI Core module".

See #3533272: Update AI module project components for more details.