pkg_resources.Environment only scans packages for the current python
version, but the checked software might be using a different python
version than the python version used to check software (the slapos
python). The checked software might also include packages for
multiples python versions.

Compute the list used python packages from the eggs directory and use
an Environment for each python version, this way we check all python
versions and also when slapos python and software python are different.

 - only consider shared parts from checked software
 - support new `.buildout-shared.json` signature files
 - unit test coverage

See merge request nexedi/slapos.core!361

See merge request nexedi/slapos.core!358

check_software was checking all shared parts, which was an easy
implementation but turned out to be problematic, both when running on
test nodes because if one software installs broken shared parts all
softwares being tested afterwards were failing and also during
development because we needed to prune broken shared parts when
fixing problems reported by check_software.

This inspects buildout's .installed.cfg to guess which shared parts
are used.

These are used in check software tests.

shutil.rmtree does not support files marked as read only by
slapos.recipe.build shared parts system and this test is now used
for testing of shared parts.

Since slapos.recipe.cmmi version 0.18, the signature files no longer
match the glob pattern that was used here, so check that shared
parts do not reference software parts was not effective anymore.

test detection of usage of shared library from system and of shared
parts referencing software

This reverts commit 2d50c8b8.

We are not ready for this, for example on debian 10 perl link with
libnsl.

For reference, one example test failure:
  https://erp5js.nexedi.net/#/test_result_module/20220111-190A520F2/20

We'll try to re-apply this later once no software use system libnsl

Since slapos commit 246be932e (component/libtirpc,libnsl: initial
inclusion, 2021-12-28) we have a slapos component, so no reason to
accept the system library

logrotate stack uses srv/backup/logrotate

This MR aims to introduce and extend the internal API with the support for manage:

   - Project
   - Organisation
   - Site (also Organisation)
   - Tokens
   - Computer Network
   
So via the introductions of workflows we included the following methods:

  - Project.approveRegistration()
  - Project.leaveProject()
  - Project.acceptInvitation()
  - Organisation.approveRegistration()
  - Organisation.leaveOrganisation()
  - Organisation.acceptInvitation()
  - Person.requestProject(project_title)
  - Person.requestOrganisation(organisation_title)
  - Person.requestSite(organisation_title)
  - Person.requestToken(request_url)
  - Person.requestNetwork(network_title)
  - ComputeNote.requestTransfer(...)
  - InstanceTree.requestTransfer(...) 
  - ComputerNetwork.approveRegistration()
  - ComputerNetwork.requestTransfer(...)
 
  
This API with minor exceptions, don't replaces the way the Hateoas/JIO website interacts with ERP5, so the original scripts are kept and just changed to call internal APIs.


See merge request nexedi/slapos.core!348

   Drop code that is never called anyway.

  This makes easy write or update tests per workflow-basis

    Drop an duplication, probably came from copy and paste

   Introduce API on person to handle the requests of Organisations and
Sites.

   This aims to transform *_createMovement into an proper API to handle location/project/owners transfers between Sites/Project/Organisations.

    This allows the project owner leave the project if he would like too

  This API aims to handle token generation for person, rather them
  keep ad-hoc API on scripts for specific usage

  Acquire listbox configuration from erp5 using proper API rather
  them hardcode the values over the .js

   - Include person.requestProject API on person_slap_interface_workflow
   - Include project_slap_interface_workflow on Projects