feat!: add foreign keys for the slices and their history

[gharlan]

The slices were the last core tables left without a foreign key, after the structure and media pool restructuring (#6667, #6668, #6670, #6671) covered everything else.

Schema

• rex_article_slice and rex_article_slice_history reference rex_article_translation via (article_id, language_id), its primary key. A slice belongs to one article in one language, which is exactly what a translation row is — referencing rex_article and rex_language separately would allow a slice for a language the article does not exist in.
• Both are ON DELETE CASCADE and ON UPDATE RESTRICT: an auto increment id never changes, so a cascade on update would only silently rewrite rows in the case that something went wrong.
• find_slices swaps its columns to (article_id, language_id) so the foreign key can use it instead of making InnoDB add an index of its own. snapshot already starts with the two columns.

Handlers

• LanguageHandler::delete() deleted the slices of the language by hand, ArticleHandler::_deleteArticle() the slices of the article. Both are redundant now and are dropped.
• The history was cleaned up by neither: deleting an article or a language left its snapshots behind forever. The cascade fixes that.
• ArticleSliceTest creates the article and its translation its slices hang off, and lets the cascade clean up.

Notes

• No migration code, as agreed for the 6.x dev state. Existing instances: delete the slices and history rows whose (article_id, language_id) has no row in rex_article_translation, then migrate adds the foreign keys.
• Verified on a fresh instance with two languages: inserting a slice for an unknown article or an unknown language is rejected, deleting a language removes its slices and history along with its translations, deleting an article removes all of them. Backend smoke test over the structure and content pages, plus the visual test fixture import, which the foreign keys accept as it is.