Trim the excessive logged stack trace for missing WARC files

[tokee]

Missing WARC files, typically caused by a dismounted network drive or a moved folder, causes excessive track traces in the logs when performing playback of webpages. This pull request changes the code to

• Log the FileNotFoundException at the root level ArcSource.get()
• Perform explicit checking for the FileNotFoundException at the calling level ArcParserFileResolver.getArcEntry(...), culling the stack trace and converting it to a proper HTTP 404 service exception.

After this pull request, the log entries from a missing WARC will be

2023-10-16 20:50:37 [http-nio-8080-exec-25] DEBUG dk.kb.netarchivesuite.solrwayback.service.SolrWaybackResource(SolrWaybackResource.java:933) - View from FilePath:/home/te/projects/wac2023/solrwayback_package_4.4.1/indexing/warcs1/mywarc.warc.gz offset:266225
2023-10-16 20:50:37 [http-nio-8080-exec-25] ERROR dk.kb.netarchivesuite.solrwayback.interfaces.ArcSource(ArcSource.java:90) - FileNotFoundException trying to access (W)ARC '/home/te/projects/wac2023/solrwayback_package_4.4.1/indexing/warcs1/mywarc.warc.gz'
2023-10-16 20:50:37 [http-nio-8080-exec-25] INFO  dk.kb.netarchivesuite.solrwayback.service.SolrWaybackResource(SolrWaybackResource.java:1135) - Handling serviceException:Unable to locate (W)ARC '/home/te/projects/wac2023/solrwayback_package_4.4.1/indexing/warcs1/mywarc.dk.warc.gz'

The first (the "real" message) is from the logger @ ArcSource and is enables closer bug finding. The second is from the Exception handler in the SolrWaybackResource and is unavoidable with the current architecture as the old contract is that the exception message will be logged here.

This closes #414

[thomasegense]

Seems simple enough I dont have need to test it.
And I agreed the stack trace was maybe too much. However this should not happen.