Update fast-classpath-scanner (2.8.1) to classgraph (4.8.104)

[NingZhuRedsilence]

Summary

fast-classpath-scanner has been deprecated; classpath is its successor. Replacing fast-classpath-scanner with classgraph caused a few code changes because the classgraph API has changed.

Additional Details

Before changing to classpath, with fast-classpath-scanner up to version 3.1.13, unit tests written using JenkinsPipelineSpecification was throwing

java.lang.OutOfMemoryError: GC Overhead Limit Exceeded

at this line.

Checklist

Testing

(Remove this checklist and replace it with "N/A - no code changes" if this PR does not modify source code)

• [x] I have manually verified that my code changes do the right thing.
• [x] I have run the tests and verified that my changes do not introduce any regressions.
• [ ] I have written unit tests to verify that my code changes do the right thing and to protect my code against regressions

Documentation

(Remove this checklist and replace it with "N/A - no code changes" if this PR does not modify source code)

• [x] I have updated the "Unreleased" section of CHANGELOG.md with a brief description of my changes.
• [ ] I have updated code comments - both GroovyDoc/JavaDoc-style comments and inline comments - where appropriate.
• [x] I have read CONTRIBUTING.md and have followed its guidance.

[NingZhuRedsilence]

1. Do existing unit tests cover the correctness of the classpath-scanning code?
2. Is it possible to add a unit test to duplicate the java.lang.OutOfMemoryError: GC Overhead Limit Exceeded exception against the original fast-classpath-scanner-based codebase, such that the test does not trigger the exception against the classgraph codebase?

1. I don't think any of the existing *Spec.groovy tests cover the correctness of the classpath-scanning code; there seems to be no Java test in the repo for now.
2. It would be possible to add a unit test as asked for, if we can recreate the state of the JVM where that error happened. But I don't know how at this moment.

However, since the newly "added" code is just calling a third-party library, I think we / I don't need to write unit test for this third-party code.

What in jenkins-spock are missing unit tests are method getClassesOfTypeInPackage and getClassesWithAnnotationOfTypeInPackage. I want to assert that adding unit tests to these 2 methods are a different and separate issue from this PR.

[corporate-gadfly]

According to ScanResult lifecycle, ScanResult should be assigned in a try-with-resources block. YMMV.