This project should be dependency-free but it requires semver

[gnidan]

In order to make web-solc very easy to use, fetchSolc() and it's chimeric cousin fetchAndLoadSolc() both allow you to specify the Solidity version as a version range, and this package's fetching logic will first invoke another of this package's exports, i.e. resolveSolc(), and determine the latest released version matching the specified range. This is useful, e.g., for users who want to quickly get started without remembering which number 0.8 release we're on (solc so prolific these days!) and in situations where users would want to pass the specified pragma solidity <version-range> directly to fetchSolc(), since that means there's no extra step on the integration side.

That's nice and everything, but there's another category of usage for web-solc besides development, and that is contract verification. In this case, the exact Solidity version is effectively already available, and thus there is no need for a version range -> version resolution. Furthermore, the inclusion of this dependency means an increased surface area for supply chain attacks for no good reason here (from the verifier's perspective).

Broadly speaking, this of course can be addressed in one of two ways:

• remove the version range stuff altogether (maybe the functionality is not that useful, no matter what... or maybe it's something to call outside web-solc's scope), or
• make semver an optional dependency

Regarding the second path:

• If this package treats semver as a regular optional dependency, then I believe it will be installed automatically anyway (pending installation issues, of which there wouldn't be any), so maybe that's pointless.
• Alternatively, it could be made into an optional peer dependency, since that should be pretty widely supported by the various package managers by now... but the downside of this is that users who want semver functionality would need to opt-in to it, and users who don't want the functionality will probably see a warning or notice every time they do an npm install, which sounds annoying.

In any event, the best course of action doesn't seem entirely clear right now, so I guess I will just let this issue stew for a bit.