Add implicit query caching support

[DarkDust]

Sparked by #337, the idea is to implement caching of parsed queries so that repeated calls to something like node.select(someQueryString) are only parsed once.

This task is meant to discuss how we want to do that. Main issue is that the caching must be limited: if a user builds dynamic queries which are not reused, a naive boundless cache would be similar to a memory leak.

Current options:

• NSCache
  • As far as I can tell, it should be available on Linux as well.
  • Automatically responds to memory pressure on Apple platforms. Not sure about Linux.
  • Major downside: it's not sendable.
• LRUCache
  • Automatically responds to memory pressure on iOS, but not yet on macOS?
  • Sendable.
  • Downside: it's an external dependency. Currently aligns with our deployment targets so should be fine.

LRUCache looks like a good fit.

Some way of configuring the cache would be nice, but in a way that's implementation agnostic so we can switch to a different cache implementation if needed/wanted.

[aehlke]

Ah I missed no macOS for memory pressure notifications that's too bad... I might look into adding it as I'm using it on Mac too

[DarkDust]

Is CocoaPods still supported? I'm asking because LRUCache "only" supports Swift Package, and SwiftSoup's podspec is outdated.

I see three options:

1. Ditch CocoaPods support completely and remove the pod spec.
2. "Vendor" LRUCache in the SwiftSoup repo and reference it in the pod spec (but use a normal package dependency for Swift Package).
3. Using #if canImport(LRUCache) I could probably use LRUCache with Swift Package and fall back to NSCache for Cocoa Pods.

Thoughts?

[aehlke]

I personally only use SPM. I understand some large projects prefer CocoaPods/Carthage still as a way to pre-build dependencies. I'm ambivalent on maintaining CocoaPods. My impression is most library projects don't offer CocoaPods these days, so teams must be adapting (not sure how - maybe they fork, or use a combination of pods and SPM).

3 is a nice idea but I doubt many people already have LRUCache or would take extra steps to add it so it would be complexity with limited utility. Unless it can be required when integrating this library via SPM, and left out as an optional dependency for CocoaPods users, that could work...

1 or 2 seem best to me. For 2 it can be done by hard forking or via submodules to keep the upstream reference and history. It is a mostly-stable single file dependency so I don't feel strongly either way.