refactor!: use ResolvedInputSource downstream of InputContent

[katrinafyi]

for parts of the link checking pipeline including and downstream of InputContent, this PR replaces InputSource fields with ResolvedInputSource. specifically, this means the structs InputContent, Request, and Response.

this makes sense for two reasons:

• conceptually, once you are able to read the content of a source, you must have resolved globs to a real path, so using ResolvedInputSource is more accurate.
• in practice, InputContent's source field was never set to a FsGlob variant, it always used variant cases which are shared with ResolvedInputSource. this is because InputContent was constructed by pattern matching out of a ResolvedInputSource - also see the *_content methods in that code snippet. so there is no loss of information in making this PR, it is just a more precise type.

in particular, the second point above means this can be done with no changes to external behaviour (there is a breaking API change, of course). in fact, this PR is almost a direct text replacement, with the gain in line count only happening because of new multi-line expressions.

this PR is motivated because when working with relative URLs and base URLs, it would be nice to know that the FsGlob case is excluded, as it would be impossible to construct a URL relative to a glob.

i've tried to make this PR reasonably thorough in its replacement of usages but notably, the stats maps are still HashMap<InputSource, ...> rather than ResolvedInputSource. i tried to change this and it led to a can of worms with InputSource implementing Deserialize but ResolvedInputSource doesn't, so i abandoned it. so, we simply convert ResolvedInputSource back to InputSource before making the statistics.

one other outstanding todo might be to use Cow in ResolvedInputSource, as InputSource now does.

this PR is just some old changes I had lying around. I'm not too attached to this PR and could get by without it. it is a breaking API change, so feel free to leave it if you wish.

[mre]

Yes, I think that makes sense.

[katrinafyi]

ResolvedInputSource now Cow as well and conflicts are fixed.

I find that the 'static lifetime used on the Cow forces clones in situations that should really be a borrow. For instance, resolve_input has lifetime parameters and should be able to return a ResolvedInputSource containing a Cow::Borrowed with lifetime 'a. Instead, we have to .clone().

But this was already a clone before this PR, so it's probably fine for now. From a quick try, hoisting the lifetime to ResolvedInputSource<'a> forces it to appear in a lot more places ;-; This can be fixed in another PR if needed.

[mre]

Great progress. Thanks @katrinafyi .

And yes, we could try a shorter lifetime. I personally wouldn't mind introducing an 'input lifetime but we'll have to see how noisy it gets. To be fair, raw string inputs are also a bit of an exception, so not sure if it's worth it.