Make libfetchers `Input` an interface with virtual methods.

[roberth]

Is your feature request related to a problem? Please describe.

The way libfetchers currently works is by making changes to an Input object, which is a mutable attrset-like map.

This makes the behavior of each fetcher somewhat harder to understand, because there's no overview of the states an Input can be in.

Describe the solution you'd like

By modeling the state of the input with actual C++ types, we - by default - canonicalize the state; reduce the entropy; making a function like fetchTree behave more predictably.

Step 1. Change Input type usages. s/Input/InputRef; and e.g. typedef ref<Input> InputRef;
Step 2. Move methods from InputScheme to Input as appropriate. Default implementations are provided that still refer to InputScheme, but InputScheme itself is not considered to be the public interface for the method anymore.
Step 3a. Subclass Input so that individual fetchers implement the new architecture
Step 3b. Make individual methods more functional.

• e.g. Combined parsing and schema generations (libfetchers, WIP) #9273 for construction

Describe alternatives you've considered

Make Input a state machine, and put virtual methods on an object contained in it. Changes less code, but I would prefer to also move the library to a more functional style.

Additional context

• Important for stabilization because this is bound to create subtle changes to its behavior. (NB they should be subtle and generally not break too many existing flakes; possibly some changes can be compensated somewhat in the flakes layer, e.g. call-flake.nix.) I hope I can keep it simple.

Priorities

Add 👍 to issues you find important.

[roberth]

Change of strategy discussed very briefly in an earlier meeting, is to add types more gradually, "bottom up", without changing Input.