Shims for old systems

[73budden]

Hi!

Every time I read "asdf", I feel a pain. I've read that there is an
attempt to gain resources to improve asdf. I have a sort of plan.

1. Shims. Recent tightening of rules for system definitions is ok, but
there are old systems with no maintainers. If such system does not
obey the rules, one can introduce "shim" concept. I've met them in JS
culture where they serve as third-party adapters to connect two
mismatching things.

In the simplest way shim is just an alternative directory hierarchy
with shim asd files, isomorphic to local lisp directory structure.

When looking for system, asdf must search in shims directory first,
and only then in the directory of the file itself. Also things like
quicklisp might take care of installing shims where they exist.
Maintanence of shims for all popular systems can be done within a
separate git repository.

2. Get rid of upgrade. Upgrade feature requires to maintain a 3d array
of possible cases, where dimensions are "old asdf version", "new asdf
version" and "lisp implementation". It is hard to maintain and it will
get harder and harder to maintain as the time goes on. Also upgrade is
a good test of CLOS, but running tests at the very beginning of image
bootstrap is not a good idea because there is no e.g. SLIME to work
with convenience.

3. Last, but most important actually. Prioritize manual, FAQ, Wiki and
all like this.

Instead, when loading asdf, allow the user to pass the parameter that
fills asdf database with the initial loaded system information. It
would be also good to have an utility to extract this database from
some old asdf versions. This way we have a slight chance to make
things easier, upgrade process explicit and under user's control.