Maven version ranges

**What would you like to be added**:
Support [Maven version ranges](https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html).

**Why is this needed**:

Maven supports specifying [version ranges for dependencies](https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html), Syft should be able to have some reasonable behavior when these are encountered. Today, Syft just injects the range as the version, e.g. `[1.2.3,)` or similar. Syft could, at least, give some best-guess or potential version, like 1.2.3 in this case, which might result in false positive vulnerability results later, but does represent something that at one time may have included that vulnerable version. In the case there are upper bounds, like `(,4.6.7]` or even more complicated multi-version ranges `(,4.6.7],(,5.6.x]`.

**Additional context**:

The only way to be entirely accurate is to reproduce Maven's dependency resolution logic, but this requires access to a Maven repository in order to query the entirety of the versions available to the system at any given time, and this value could potentially change as software moves forward, so perhaps there is something that looks these values up, but we should be able to surface reasonable packages based on these possible range-specified versions.

Additionally, we can improve the Package version determination algorithm to be slightly better by eliminating duplicate packages with different versions by including the versions of the same package closer to the top of the graph -- e.g. in a transitive dependency relationship, the , if that still reasonably matches the Maven logic. Regardless of other improvements to the Maven logic here, capturing this range information could be useful. To a degree, also it would be possible to match certain vulnerabilities based on ranges.

Note: there are other ecosystems that support version ranges, and Syft should have some common behavior for these. If it makes sense, some centralized logic and possibly configuration, even on a per-ecosystem basis to deal with version ranges might be useful; perhaps this is part of the compliance behavior to either: drop, best guess, or lookup.

Start by tracing Syft’s current Maven dependency version handling and how it records range strings such as [1.2.3,). Review the desired best-guess, upper-bound, duplicate-resolution, and cross-ecosystem behaviors, then define tests that establish the selected behavior and its completion criteria.

Written by the indexing model from the issue text.