Parse affected ranges only once

Previously, the version range matchers used by vulnerability scanning
always constructed a new affected range when calling the `affected?`
method. If called sparingly, the performance of the method can be seen
as acceptable, but if done continuously - in a loop for example - then
the performance of the matcher begins to suffer. To address this, the
matcher class now initializes the affected range only once at the
beginning, and re-uses the same instance for future comparisons. This
means that we improve the memory footprint significantly when it's
called in loops as is the case with Continous Vulnerability Scanning
where we've seen allocations in the realm of GiB. By proxy, this
improves the performance of the Sidekiq instance that CVS runs on
because the garbage collector does not need to prune as many unreachable
objects in memory.

Changelog: performance