Migrating the blog categories replaces the shipped Blog.Categories pages with the legacy ones

The category location migration (Blog.Code.CategoriesLocationMigrator, $services.blog.migrateCategoryLocation()) moves every category page of the Blog space to Blog.Categories. The extension still ships the legacy category pages Blog.Categories, Blog.News, Blog.Other and Blog.Personal (with a Blog.CategoryClass object) next to the new ones (Blog.Categories.WebHome, Blog.Categories.News, ...). The migration renames them too, overwriting the new pages:

• Blog.Categories.News, Blog.Categories.Other and Blog.Categories.Personal are replaced by the legacy pages (losing their changes and history)
• Blog.Categories.WebHome is replaced by the legacy Blog.Categories page, which has a Blog.CategoryClass object: the categories home page becomes a category again (see BLOG-238)
• the pages Blog.News, Blog.Other, Blog.Personal and Blog.Categories of the extension are deleted (the installed extension is then seen as modified)

Steps to reproduce

1. Have a blog post in a legacy category (e.g. Blog.Travel) so that the migration is proposed
2. Run the migration from Blog.Code.CategoriesLocationMigrator
3. Look at Blog.Categories.WebHome and Blog.Categories.News

Cause

CategoryLocationMigration.java:158-169: the query selects all the Blog.CategoryClass pages of the Blog space except Blog.CategoryTemplate, so it includes the default categories of DEFAULT_CATEGORIES (already handled without a rename by migrateDefaultCategories), which are then renamed with overwrite = true. They should be excluded.

The current behaviour is pinned by CategoryLocationMigrationTest#migrateReplacesTheShippedCategoriesWithTheShippedLegacyOnes (BLOG-269).