[FEATURE] Enable queries using "root" and "-1" for pidInList

The version preview in the frontend rendering process basically
selects only the live versions and then overlays those records
with possible versions. Since the MM handling is changed to
directly point to the most specific version in that regard (this
is an exception to the "always live, overlay then" approach), the
versions also need to be selected directly. ContentObjectRenderer
uses the method PageRepository::enableFields() which adds an
additional SQL WHERE part, like " AND tablename.pid<>-1" to
exclude possible versions.

Besides that, elements (like sys_catagory) that are stored on the
root-level cannot be queried at all which leads to custom code in
the end just to perform these queries.

This change allows selections on the root-level and disables the
"pid<>-1" constraint if the opposite has been defined in the
pidInList property.

Example:
select.pidInList = root,-1

Resolves: #57168
Documentation: #57171
Releases: 6.2
Change-Id: I6fb91f89f70614d59c83d808f07e890833248880
[BUGFIX] Invalid relations of IRRE records in workspaces

* general -> always use live id as pointer value
* create records -> automatically fill placeholder pointers
* copy records -> currently leads to problems with sorting
* move records -> follow and create child move placeholders
* delete records -> forward delete data in copy(!) process
* ReferenceIndex needs to hold the most specific relations
  since the CommandMap handler is based on this information
* ReleationHandler is extended for IRRE references to fetch
  the live default parent pointer automatically (this new
  behaviour can be disabled by public methods for each
  RelationHandler instance)
* The method version_swap_procBasedOnFieldType of the version
  DataHandlerHook is completely removed since IRRE records are
  now referenced using the live default parent pointer value
* UserTSconfig property options.workspaces.swapMode is set
  to "pages" per default - thus, if a page gets published all
  accordant records on that page are published as well

Resolves: #56376
Releases: 6.2
Change-Id: I75248d10b000de73ca623770f07e8c2e89d4cdd8
[BUGFIX] Invalid relations of MM records in workspaces

The basic problem with MM (ManyToMany) relations in workspaces is
that the intermediate table (MM table) does not have any
information about actually being a reference in a particular
workspace - there is no "t3ver_wsid" field. Thus, the meaning of
a relation needs to be determined from the entities on both sides
of the relation. The following is possible:

* both sides are live -> valid in live only
* exactly one side is versioned -> valid in a workspace only
* both sides are versioned -> valid in a workspace only

The difficulties now start with versioning one side first and
after some time the other side - thus the relation with exactly
one version and one live entity needs to be turned into an entry
pointing to both versions.

Resolves: #57169
Releases: 6.2
Change-Id: Idb043d520c30f15e85d54a016e52690f5f05cedc