Call resolver dynamically upon call to \lyp-require, \lyp-include etc

[noteflakes]

See also #61.

Currently the resolver scans any dependency declared, then checks all included files. This leads to problems when we wish to do fancier stuff, like \lyp-require #'(a b c d), or invoking the lyp API from scheme code. It also means we need to scan any possible include file before Lilypond starts to process the file.

So, idea is to get rid of the pre-processing scanning of files, and invoke the resolver inside of lyp:require. That means:

• The resolver is a bin script that is run from within the lyp:require scheme procedure.
• It returns a text representation of a scheme object containing info about the package - name, version, entry-point path.
• The resolver selects the best version that satisfies the package ref. If a different version of the package is resolved later, lyp:require should throw an error.
• If the dependency is not found, lyp:require should throw an error.

Plan of action:

• Provide path to resolver bin script in the dynamically generated wrapper.
• Infrastructure to run resolver script with the dependency reference as command line argument.
• Receive output from resolver script, eval it into a scheme object and process it.
• Handle errors (dependency not found, version ambiguity)
• Profit!

[noteflakes]

Another thing that should be taken into account: if dependencies are all defined in an external file, it might help the resolver to make smarter decisions about versions, as it does now. So we have:

• Dynamic resolution of dependencies.
• Ahead-of-time resolution of dependencies.

These two things are not mutually exclusive. Let's say for example that dependencies can be defined in a lyp.conf file. This file is optional - it just allows the resolver to make smarter decisions about versions. So, if such a file containing all dependencies exists, the resolver uses it to resolve the different versions before the file is compiled, and injects the information into the wrapper script handed to Lilypond. If any dependency is not found in lyp:package-refs/lyp:package-dirs, the resolver is called in-process to resolve them.

What might the lyp.conf look like? JSON? YAML? Plain-text? We may start with a plain-text file containing simply a list of package references (with version predicates):

a@0.1
b@~0.2
...