We call those subs impossible which use a combination of variables not
being available together from any of the built-in subroutines (aka
methods), for example::

        sub foo {
                set req.http.impossible = beresp.reason;
        }

For this example, there is no built-in subroutine for which both req
and beresp were available, so it can not possibly be valid in any
context.

As long as subs were actually called directly or indirectly from a
built-in sub, VCC did already detect the problem. For the above
example, if `sub vcl_recv { call foo; }` existed, VCC would complain
about beresp.reason not being accessible from vcl_recv.

Except, when vcc_err_unref was disabled, the example would pass
without error, and likewise it will with calls which we are about to
add.

We now add a check to detect impossible subroutines. It happens in a
second walk over the VCL's SUB symbols in order to keep the more
precise error messages for calls rooting in one of the built-in subs.

This change also changes the order of error reporting slightly and
incorporates, indirectly, the vcc_CheckUses() check moved in
ed36b638.

v00020.vtc now has the "Impossible Subroutine with vcc_err_unref off"
check, while the newly added m00053.vtc has been changed to test
failure of the impossible sub at compile time rather than at runtime.

This change was triggered by feedback from Dridi