When working on the issue
#1391 I realized that the
migration guide was a bit outdated and had multiple important issues to
address.

I have refined the content and applied major updates.

Updated docs:

- [Migrate your Elasticsearch
data](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/1426/manage-data/migrate)
- [Migrate system
indices](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/1426/manage-data/migrate/migrate-internal-indices)

Summary of fixes and changes:
- Internal / system indices migration based on snapshot was incorrect ->
feature states should be used.

- Internal / system indices migration based on reindexing was incorrect
-> the procedure was faulty and needed extra love and research. But
considering that based on Elasticsearch docs we state that from 8.0
onwards, `feature states` are the only way to backup and restore system
indices and system data streams, I have removed the reindex option for
this.

- Snapshot repository creation for ECE was invalid, as users shouldn't
create a repository for data migration at ECE-level, but directly at
deployment-level (this is a gap in our docs as we don't have specific
ECE docs to create custom repos only at deployment level) -> The ECH doc
is valid for this, so ECE users can follow the ECH doc to create a
custom repo at deployment level.

- Added a lot of links to other relevant documents of the new IA. The
intention of this document is to feel like a narrative document
explaining what to do and how, but with links to the official snapshots
or reindex documentation for more information.

- For reindex method, I have added explanations and recommendations for
mappings and index templates handling, without specific instructions
(just pointers).

- The previous doc presented the official doc about Backup Snapshot
repositories in a context where it didn't belong. I've included a tip
explaining a use case where that can be useful.

- The previous doc suggested the usage of a `url` type repository in a
way that felt incorrect (together with AWS / GCS / Azure keystore
credentials which in my opinion cannot be related). I've added it as
another possible use case (I'm still not 100% sure about this, and we
have some contradictions in other documents that we have to address
separately).

Closes: #1391

---------

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>