Move the logic that resolves where a blog's posts and categories are located to Java

Why

Today the rules that decide which blog a page belongs to, where a blog's posts are stored and where its categories are stored are implemented in Velocity, spread over many wiki pages:

• the Blog.BlogCode macros #getBlogDocument, #getBlogPostsLocation, #getBlogCategoriesLocation and #getBlogDocumentForCategoriesSpace
• Blog.BlogParameters, Blog.CategoriesCode, Blog.ManageCategories, Blog.Management, Blog.CreatePost, Blog.BlogPostSheet, Blog.CategoryRss, Blog.BlogPostList
• the categories and related blogs panels

The same rules are re-implemented, with slight differences, in several of these places. This has caused several bugs (BLOG-271, BLOG-272, BLOG-277, BLOG-278, BLOG-279, BLOG-281, BLOG-283, BLOG-284) and makes the rules hard to unit test.

Goal

• Resolve these locations in a single Java module, exposed through the blog script service ($services.blog).
• Keep the existing Velocity macros for backward compatibility, as one-line delegates to the script service.
• Make the wiki pages call the script service directly.
• Introduce a small storage seam (blog posts using a category, subcategories of a category, legacy categories of a wiki, moving a category) with an XWQL-based production implementation, so that the location logic, CategoryRenameListener and CategoryLocationMigration can be unit tested without faking queries.

Scope

This is a refactoring with no change in behaviour: the existing characterization tests (BLOG-269) must stay green, including the ones pinning known bugs. Those bugs are fixed afterwards, each in its own issue.