migrate mapping & messages table names are truncated, can lead to incorrect mapping lookups

I was thinking about #47 🐛 migrate mapping & messages table names are truncated, can lead to incorrect mapping lookups Needs work , where two migrations are sharing a map table name. While it is rare, it is possible. If a site is in such a situation then changing the tables names could break their migrations. In fact, it would if they are using migration_lookup. A migration using a 'shared' table would start using a new table and thus not have access to the older data. If this was detected we could copy the data to the two new tables and everything should be fine.

But, maybe a simpler way is to not modify the table names when it is detected that 'shared' tables are in use. When 'shared' tables are detected a flag could be set, in key/value, to indicate that the older method for computing table name should be used. And if that flag is not set then the new method is used.

Setting to NR for comment on this idea.

BAck to NW since there is still work to do and no comments for a month

@mikelutz, before work continues I think we should have direction on how to handle #47. I proposed an idea in #65.

@quietone on ##6:
I think I'd like to have two copies of the same table more than having to maintain that legacy way of handling migrate tables.
If we decided to follow the flag way, one day we would certainly like to deprecate that and prepare a new upgrade path that would be the same as the one we would code today, isn't it?

Rerolled #53 on HEAD in a MR.
Fixed phpcs and phpstan issues.
Updated the upgrade path to clone tables instead of renaming them. (I wish I could use a Merge query for this but... 🐛 Merge queries should allow setting the conditionTable Active )

In other situations like this (cache IDs in the database backend, maybe field/bundle names), we hash the end of the ID if the entire thing is too long. It's not great for readability but it doesn't require an update path.

@catch #71: This is exactly what this issue is about. The original issue was caused by the fact the tables names were only truncated. Now we hash the end but we still have to handle the existing values, hence the upgrade path.

I am worried about how disruptive this change could be. Since both @catch and @daffie have commented on this issue, and neither seems concerned about that, I guess it is OK. But I am adding the tag for a change record (NW for that) and I am adding a release-notes snippet to the issue summary.