reference has two meanings (now that it lost the "login" meaning):
- technical user identifier
- regular ERP5 document reference
This change moves the former to the new "user_id" property.
The latter remains in the "reference" property.

This adds a new portal type category, "login", and corresponding
getPortalLoginTypeList portal-level getter.

Now that a user can have multiple logins, create_user_action becomes
always available.

In addition to ERP5 Login-based authentication and enumeration support,
reserve special Zope users.

patches/DCWorkflow: use 'user/getIdOrUserName' as workflow actor expression instead of 'user/getId'.

so that ID is used for ERP5 user case, that should never change, and User Name is used for system users
like Anonymous User or System Processes, without changing all workflow definitions.

so that getId() is used for ERP5 users and getUserName() is used for special users
like Anonyous User or System Processes whose id is None.

To prepare for moving user id to a different property.
Mostly replacing getReference on Persons with Person_getUserId, and
catalog searches with PAS API when it is meant to search for a user and
not really a person by reference.

Because unit tests were used to choosing a login and setting a password,
making them use such method seems easier than adapting them to use the
existing "login" method, which really works by user id and not by login.

use getId() instead of getUserName() where user is supposed to be neither Anonyous User nor System Processes.

Apply security in ERP5User methods.

Require the findings to be consistent when applicable.
May happen for example when migrating a user from being handled by one PAS
plugin to another.

It does not depend on a specific plugin.
Also, update all importers.
Also, reduce import cycles in ERP5Security.

The value used to be displayed will be the last value of the tuple

This is "Internal Trade Condition", not "Purchase Trade Condition"