Refactor pipeline to extract reusable basepipeline in module and library

[tdruez]

This PR refactors the pipelines architecture to extract a reusable BasePipeline in its own module and also available as standalone library

This is going to support adopting pipelines in VulnerableCode and PurlDB

Reference:

• Extract base pipeline code for reuse in other projects  #1351
• Use the SCIO Pipeline Mechanism for Importers/Improvers vulnerablecode#1509
• RFC: Adopt scancode.io "pipeline" approach for visit/map/collect  purldb#521

[tdruez]

The code in this branch is currently experimental and not ready for merge/production.

[pombredanne]

the "pipeline" module name needs to be changed to something better that will not conflict when installed with other libraries.

I suggest either:

• using a namespace (we never did before, but we could start). This would mean creating a top level aboutcode directory with no __init__.py and a few more details TBD. This is PEP420 https://peps.python.org/pep-0420/ and https://docs.python.org/3/glossary.html#term-namespace-package and this namespace would become reusable across other projects for shared modules. This is OK because we own aboutcode on PyPI and none of our projects ever used the aboutcode module name. Some exmaples include jaraco's repos at https://github.com/jaraco/jaraco.vcs https://github.com/jaraco/jaraco.abode and https://github.com/jaraco/jaraco.context all living in the same "jaraco" namespace.
  In this case I would suggest that we call the package pipeline under aboutcode namespace. And end up with this path aboutcode/pipeline/__init__.py

• using another name for the package directory that contains __init__.py and use that as a regular, non-namespaced module. For instance aboutcode_pipeline/__init__.py

There are no specific benefits nor issues with the second approach. Using the first approach with a namespace would be the pythonic way.

We should name the wheel aboutcode.pipeline to make it unique.

[tdruez]

This PR is already too complex combining the module refactoring, the Pipeline classes refactoring, packaging logic, and new CI for release publishing.

Let's split this into manageable and simpler-to-review parts:

• Move the current BasePipeline class to a new aboutcode.pipeline module without any code logic changes. Move the BasePipeline class to a new aboutcode.pipeline module #1351 #1357
• Refactor the BasePipeline to remove the scanpipe.Project logic and make it reusable without Project context. Refactor the BasePipeline, move out all Project related logic #1351 #1358
• Add the packaging and release system Add pyproject.toml for packaging aboutcode.pipeline module #1351 #1359