BC: redesign for PURL 1.0

PackageURL 1.0 was releqsed - https://github.com/package-url/purl-spec/releases/tag/v1.0.0 🎉

with this, we can finally rework the whole implementation to adhere the final Spec.

blockers

Unfortunately, the spec is not entire explicit, the actual grammar is not part of the spec, yet
Implementing the implicit rules of the spec is error-prone, relying on non-spec rules like how-to-build.md and how-to-parse.md is kind of a "best-effort" implementation. Therefore:

• waiting for https://github.com/package-url/purl-spec/pull/578

expected outcome

• have a namespace PackageUrl\Core - everything defined in the STANDARD and in additionalmaterial
  • data models and enums andconstants - https://github.com/package-url/purl-spec/blob/main/docs/known-qualifiers.md
  • parsers - https://github.com/package-url/purl-spec/blob/main/docs/how-to-parse.md
  • stringifiers and canonicalizers - https://github.com/package-url/purl-spec/blob/main/docs/how-to-build.md
• have a namespace PackageUrl\Types - for implementations related to specific types
  • empty at first
  • add an example implementation for composer - https://github.com/package-url/purl-spec/blob/main/types-doc/composer-definition.md
• have a namespace PackageUrl\Contrib - for everything not defined in the standard
  • empty at first

have tests for the core implementation and the implanted type(s) -
shall use the tests provided by https://github.com/package-url/purl-spec/tree/main/tests

have the README tell about the different sub-namespaces and their purposes.

Start with the PURL 1.0 standard, known-qualifiers, parsing, building, and types documentation, while checking the status of package-url/purl-spec pull request 578. Use the provided PURL specification tests as the first validation point; done means the Core, Types, and Contrib namespaces, Composer example, README guidance, and core/type tests are in place.