feat!: make `bom-ref` part of equality checks

[jkowalleck]

context

Currently, components that differ only in the property bom-ref are treated as equal.
This is for the reason, that bom-ref is actually just a decorative marker for interlinkage.

Anyway, there are external tools and processes that produce CycloneDX like this:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
      "component": {
      "type": "application",
      "name": "example",
      "version": "1.2.3",
      "bom-ref": "topref"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "styled-engine",
      "version": "5.16.6",
      "bom-ref": "@mui/styled-engine@npm:5.16.6 [296f2]"
    },
    {
      "type": "library",
      "name": "styled-engine",
      "version": "5.16.6",
      "bom-ref": "@mui/styled-engine@npm:5.16.6 [3135b]"
    }
  ],
  "dependencies": [
    {
      "ref": "topref",
      "dependsOn": [
        "@mui/styled-engine@npm:5.16.6 [296f2]",
        "@mui/styled-engine@npm:5.16.6 [3135b]"
      ]
    }
  ]
}

These are, schema-wise, valid CycloneDX.

the problem

when these things are imported by this library, the components get deduplicated (since they are equal) - which causes issues with the dependency tree - and alternates the structure when exporting.

solution

bom-ref MUST be taken into account for the following processes

• equality and comparison (__eq__, __lt__, __gt__, ...)
• hashing (__hash__)

❗ Since BomRef will become a central part of hashing and comparison, we need to revisit the respective dunder methods on BomRef.

related

closes #753

[jkowalleck]

@madpah FYI

[jkowalleck]

I will work on a fix, soon.

• feat!: BomRef affect equality/comparisson #754

[hirsche]

I'd ask for this one as well.

I was debugging my code for ages, not getting why some of my "LIBRARY"-Components, I have been adding successfully, where lost after adding other components - well just because they where regarded as the same component and then got overwritten with another component having a different bom-ref but same name.

Of course usually you'd have more properties assigned making them distinguishable over the hash, however, when you start with some basic code and add an "assumed-to-be-a-reference" it is a bit confusion when components get lost.

[jkowalleck]

A preview of the fix/feature is available via https://github.com/CycloneDX/cyclonedx-python-lib/releases/tag/v9.0.1-rc.1