Encoding of PURL and CPE in Alpine

### Current Behavior

SBOMs obtained by scanning containers based on an official Alpine Docker base image contain a list of elements coded with an internal Alpine revision number.

An example might be the presence in the Alpine base image of components such as:

cpe:2.3:a:busybox:busybox:1.35.0-r31:*:*:*:*:*:*:*
pkg:apk/alpine/busybox@1.35.0-r31

The “-r31” tag informs that busybox v.1.35.0 is used in the base image, but that it has been patched to fix some vulnerabilities using an internal Alpine “r31” release.

The use of cpe and PURLs that contain this "-r*" has two effects:

- Dependency Track is not able to notify the presence of a vulnerability in this SBOM (because it does not recognize cpe:2.3:a:busybox:busybox:1.35.0-r31 as the busybox v.1.35.0 package (probably because a strict string comparison based on cpe or PURL is used in the check).
-
- Dependecy Track does not check whether or not this specific “-r31” revision of the package is still affected by the vulnerability because Alpine Security Tracker (https://security.alpinelinux.org/) is not available as a vulnerability DB source.

Other vulnerability scanners like grype (https://github.com/anchore/grype) check and recognize this "-r*" coding signaling the presence of vulnerabilities only for the affected "-r*" revision handling the Alpine ecosystem.

Given the widespread use of Docker Alpine images in building docker based solution we ask to integrate Alpine PURL and CPE coding.

### Proposed Behavior

- Check PURL and CPE keeping in mind this particular use of the package identifier made by Alpine
- add the Alpine ecosystem to Dependecy Track

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested