Merge remote-tracking branch 'origin/main' into t266-installers

# Conflicts:
#	share/filelist.md5

Merge origin/main into member management: the audit catalogue counts the events of both, the kernel autoload array keeps the classes of both

Merge remote-tracking branch 'origin/main' into expui-lines

# Conflicts:
#	share/filelist.md5

Merge remote-tracking branch 'origin/main' into pwchange

# Conflicts:
#	share/filelist.md5

Updated: The member management guard asks only users with a limited policy, and the audit catalogue test counts its two new events

- The guard of the access check now looks at an account's other locations
  only when the user's policy for the function is limited: a user with the
  function everywhere passes every location anyway, and an allowance without
  a policy (the user's own new draft) concerns no existing account. This keeps
  the database out of the check for administrators and for the access check's
  tests without a database.
- user/setting's refusal passes no result of its own, as the other early
  returns of the view do.
- expAuditRecordTest counts access.user.change and access.user.move in the
  catalogue (173 names, 123 on by default).
- The member management note says that protected groups stay with the
  administrators and that the events are generic, without naming a later
  approval path.

Tested again on the throwaway SQLite installation: the by-use run of a
throwaway editor passes on the admin and the editor siteaccess.

Added: Member management: editors manage the site's members, never administrators or editors, with every action audited

Editors of a new installation could not manage the site's front-end members:
the Editor role reads and edits nothing below Users. Owner decision: editors
manage members fully by policy, limited to Members, and every action is
recorded.

- settings/membermanagement.ini says which user groups manage which others
  ([MemberRule_<name>]: manager groups, managed groups, a policy set, a role),
  which groups are never managed through a rule (ProtectedGroups[], default
  Administrator users and Editors, by remote id) and which policies a manager
  gets ([MemberPolicySet_<name>], module/function;Limitation=values lines).
  The default gives the Editors group the role "Member management" over
  Members: read, create users and user groups below a user group, edit (name,
  e-mail, login, password), remove, move, the versions, user/preferences for
  enable and disable, and read on the user root alone for the Users tab. Every
  content policy carries the managed subtree; the role is assigned without a
  limitation.
- A rule whose managed groups reach a protected group, whose manager group
  lies in its own managed group, or whose policies name module/*, an
  administration module, an unknown class or their own Subtree/Node is refused
  whole; a policy is never widened.
- expMemberManagement::ensure() runs in the setup wizard and the kickstarter
  after the site package's roles (every package and base data);
  bin/php/addmembermanagement.php (--dry-run, --rule) applies the rules on an
  installation that exists, adds only what the role lacks and checks the
  result (PASS/FAIL).
- The access check of eZContentObject and eZContentObjectTreeNode: an allowed
  edit, move, remove, location change, hide, translate or version removal of an
  account with a location below a protected group holds only when each such
  location allows it on its own, so a Subtree policy on Members no longer
  reaches an administrator who also has a location there. A managed group
  itself needs the function at its parent, so a manager cannot rename, move or
  remove the whole Members group.
- user/setting also asks for content/edit of the account
  ([MemberGuardSettings] SettingRequiresEdit): user/preferences alone, a
  function without limitations, reached every account of the installation.
- Audit: access.user.change records the fields of an account that changed,
  before and after, from any interface (never the account attribute: login,
  e-mail and password keep their events, the password is never recorded);
  access.user.move records a move to another group; a refused view names the
  account it was about (id and login), also for content/action from its form.
- Upgrade note doc/eng-us/bc/6.0/member-management.md (settings, guard,
  audit events, variations, the approval path left to protected groups) and
  the 6.0.15 changelog.

Tested on a throwaway SQLite default installation (exp:install) served by the
built-in server: the setup step made the role and assigned it to Editors, a
second run of the command adds nothing. A throwaway editor, on the admin and
the editor siteaccess alike, created a member group and a member, changed the
member's name, e-mail (waiting for the member's confirmation) and password
(the member signs in with it), disabled (sign-in refused) and enabled it, moved
it into the new group and removed both; was refused editing, disabling,
removing or moving an administrator, another editor and an administrator with
a second location below Members, editing, moving or removing the Members group,
moving a member into Administrator users or Editors, creating a user there,
and the role, section and setup views. The audit log held the create, the
change with its before/after fields, the password change, disable, enable,
move, remove and every refusal with the target's login.
expMemberManagementTest checks the plan and the rules without a database.

Updated: The test autoload array takes no class of a stand-in file and no class the installation loads at run time

The test array (ezp_tests.php) is merged before the extension array, and the
kernel autoloader runs before Composer's. It took every class of an extension's
tests/ that was not a kernel class, so the PHPStan declarations 7x SQLI Import
2.0.0 keeps there (a hollow ezcBaseOptions, eZPersistentObject,
expDataTableCatalogue ...) were mapped: the first test that autoloaded
ezcBaseOptions loaded the hollow one and stopped with "Class
ezpExtensionOptions contains 4 abstract methods", and a later test redeclared
the kernel classes.

A test class named like an extension or Composer class is refused now, as a
kernel one already was. A file that declares a kernel, extension or Composer
class outright (not inside an if) is a stand-in file, and none of its classes
is taken. The tests directory one extension's own suite reads
(testsClassMap()) keeps the stand-ins' other classes, as its bootstrap has
loaded them already.