Child pages of a page with a dot in its name disappear from the page tree when the parent page is deleted

Reproduced on XWiki 18.4.2 with PostgreSQL. The same code is used on 17.10.x and master, and MySQL / MariaDB are affected in the same way (they also use the backslash as the default LIKE escape character).

Reproduction steps

1. On a wiki using PostgreSQL, MySQL or MariaDB, create a page named a.b (with a dot in its name) at the root of the wiki.
2. Create a child page c under it, i.e. a.b/c.
3. Delete only the page a.b, keeping its child page.
4. Open the page tree (e.g. the Navigation panel, or the Document Tree macro) and expand the root of the wiki.

Expected result

The page a.b is still displayed in the page tree (as a node for a deleted page that still has children), and its child page a.b/c can be reached from it, as happens for a page without a dot in its name (doing the same with x and x/c keeps x in the tree).

Actual result

The whole a.b subtree disappears from the page tree, although the page a.b/c still exists and can be accessed directly.

In the database, the xwikispace row for a\.b has been deleted while the row for its child space a\.b.c still references it as its parent:

 xws_reference | xws_parent
---------------+------------
 a\.b.c        | a\.b
 x             |
 x.c           | x

The cause is XWikiHibernateStore#hasDocuments(), which looks for the children of a space with space LIKE :like using the serialized local space reference followed by .% (here a\.b.%), without escaping the value and without an ESCAPE clause. On PostgreSQL, MySQL and MariaDB the backslash is the default escape character in LIKE patterns, so a\.b.% only matches a.b.<something> and not the stored a\.b.c. The space is then considered empty and maybeDeleteXWikiSpace() removes it. The special LIKE characters % and _ are not escaped either (see XWIKI-16331, where the problem was hidden by a check done afterwards in Java, which only removes wrong matches and cannot add back missed ones).