Update paths

When determining update paths, also known as upgrade edges or upgrade constraints, for an installed cluster extension, {olmv1-first} supports {olmv0} semantics starting in {product-title} 4.16. This support follows the behavior from {olmv0}, including replaces, skips, and skipRange directives, with a few noted differences.

By supporting {olmv0} semantics, {olmv1} accurately reflects the update graph from catalogs.

Differences from original {olmv0} implementation

If there are multiple possible successors, {olmv1} behavior differs in the following ways:
- In {olmv0}, the successor closest to the channel head is chosen.
- In {olmv1}, the successor with the highest semantic version (semver) is chosen.
Consider the following set of file-based catalog (FBC) channel entries:
```
# ...
- name: example.v3.0.0
  skips: ["example.v2.0.0"]
- name: example.v2.0.0
  skipRange: >=1.0.0 <2.0.0
```
If 1.0.0 is installed, {olmv1} behavior differs in the following ways:
- {olmv0-caps} will not detect an update path to v2.0.0 because v2.0.0 is skipped and not on the replaces chain.
- {olmv1} will detect the update path because {olmv1} does not have a concept of a replaces chain. {olmv1} finds all entries that have a replace, skip, or skipRange value that covers the currently installed version.