Make sure nested classes actually, you know, work. Test added!

    class c1(integer v1) {
        class c2(integer v2) {
        }
        var @v = c2::new(1)
        }
    }
    var v = c1::new(1)

This snippet was reporting that c1::new takes 2 arguments, not one. So the first
thing that was done was to make sure that a nested class constructor doesn't
automatically get a 'self' of the parent class...because that's wrong.

But then calling c2::new started to crash. It turns out that the reason was that
the vm was not loading the functions of scoped out classes. This was trivial to
fix.

Added a test to pre-commit-hook.py to prevent this from happening again.
Remove invalid cliexec-targets. pre-commit-hook.py tests it well.
Rip function decl and regular decl parsing apart.

So...since the beginning of Lily, the proper way to enter a function has been
to call collect_var_sig with CV_TOPLEVEL and CV_MAKE_VARS. Later it was
changed to take a starting class too.

When classes came along, that was added to: To enter a function, call
collect_var_sig to collect the function type (and at the same time enter the
function but don't mention that).

That functionality has now been stripped from collect_var_sig. The proper way
to enter a function (internally) is to call...parse_function. This parses the
header and actually enters the function. No more, no less.

I've also simplified the logic for handling generics and stuff for functions.
On the outside, there is no change. Internally, a function that did two things
has been cut into two functions.

Use collect_var_sig to collect sigs only now.

I did this as part of clearing up a bit of the mess that generics have brought
with them.