Fix crash when a class constructor takes a container. Test added.

I was trying to add better defaulting and got...side-tracked when trying to
add something that would be needed before it. I realized that there wasn't a
lot of testing of the generic stuff, so I decided to run a couple tests.

This is what was crashing:

    class ListHolder[A](list[A] value) { list[A] @value = value }
    ListHolder[integer] holder = ListHolder::new([1])

This would crash in a infinitely recursive loop (fun!) trying to figure out
how to resolve the type of @value. This crash was caused by not one, but two
bugs:

Bug 1:
When a generic function is called, the vm uses the types given to parameters
to figure out what the vars and storages inside the function should be. This
should never fail, because generic types always require an assignment.

The constructor to ListHolder presents an interesting problem: There is a
list[A] given, and a need to make a resulting Point[A]. To make a long story
short, resolution didn't account for that, so Point[A] came out as Point[A]
instead of properly mapping it out. The resolver now understands that if it
needs a generic and cannot find it, then one of the parameters MUST have it,
and it MUST dig to obtain it.

Bug 2:
If the class property resolver needs to resolve something, it would walk over
each individual sig that needed resolving. So far, that's okay. But...if it
found an element that needed resolving, it would send the parent. So any
complex element was bound to crash in an infinite loop. Yikes.

Semi-related, but I also fixed debug's instance dumper so that properties with
a container type (like a list) get that list value indented properly. It looks
wrong otherwise.

A test has been added to pre-commit-hook.py, so that this won't come up
again.