Allow KnownHostsServerKeyVerifier to read from a resource URL

### Description

Hi,

Currently all `KnownHostsServerKeyVerifier` constructors accept a `java.nio.file.Path` argument to the `known_hosts` file. I would like to request the addition of an additional constructor which accepts a `java.net.URL` argument, as returned by `java.lang.Class.getResource(String)`, and potentially points to a `known_hosts` file which exists as a resource inside a jar file.

### Motivation

I have a Java application which uses SSH to connect to a number of internal servers within our organization. I am replacing the invocation of the system provided Open SSH with mina-sshd bundled with the application, allowing it to run out-of-the-box on platforms like Windows (developer workstations), or within vanilla container environments that would not normally come with SSH installed (ex: a Tomcat container).

However, OpenSSH still makes for a quick and user friendly tool for building and maintaining a file of known_hosts for our internal servers, a file which can easily be dropped/updated into the project as a resource file. This file is obviously intended to be read-only in this environment.

### Alternatives considered

I contemplated implementing my own `ServerKeyVerifier`, but `KnownHostsServerKeyVerifier` already has all the logic for reading this format file, iterating through the list, and matching results, etc. I ended up extending `KnownHostsServerKeyVerifier` with my own subclass that accepts a URL, and when it's supplied a `known_hosts` file that's within a jar, calls `KnownHostEntry.readKnownHostEntries(URL)`, does `AuthorizedKeyEntry.resolvePublicKey(null, null)` on each result, and builds it's own static list of `HostEntryPair` values, where it then overrides `checkReloadRequired` to always return `false`, and overrides `reloadKnownHosts` to return it's static list. This hack obviously required some digging to code, and represents a fragile maintenance burden I'd rather not bear long-term.

### Additional context

Interestingly, I didn't encounter this problem loading the private keys as resources from a jar file, as `KeyPairResourceLoader.loadKeyPairs(SessionContext, URL, FilePasswordProvider)` exists. And it's worth noting you do have `KnownHostEntry.readKnownHostEntries(URL)` already, just not extending that URL functionality to `KnownHostsServerKeyVerifier`.

Start by inspecting the KnownHostsServerKeyVerifier constructors and reload behavior, then compare them with KnownHostEntry.readKnownHostEntries(URL) and the existing Path-based flow. The work is done when a verifier can read a known_hosts resource from a URL, including a resource inside a jar, while preserving the existing host matching behavior and read-only semantics.

Written by the indexing model from the issue text.