Only test abstract model once.

The implementation of Set_tech_storage and Set_tech_baseload are the
exact same, as they are both merely instantiations of
TechnologySetMember.  Until their functionality changes, there is no
need to test them both; one will do.
Robustify LifetimeParameter.__unicode__
Incorporate some validation into LifetimeParameter

Unit testing brought this forward that the model was not validating it's
input.  Nice.
LifetimeParameter unit tests.
Clean the name before saving.

There's currently no UI to put in new item in this table, other than
through the Admin interface.  However, from the department of "just in
case".
CommodityType unit tests.
Another CommodityType unit test.
Start testing forms.

The forms are the main interaction below the API, so we need to make
sure they're correct.  This starts unit testing, with the LoginForm.
Add some more error checking to LoginForm.

It shouldn't be a problem, but let's just make sure some common
"bad characters" aren't in the username or password.
f is shorter than form.  For the lazy.  Which I am.
Check more than one bad character.
Unit test AnalysisForm.
There should be no "vertical tab" in a name.

Identified missing removal during testing.
Remove empty fields.

These might occur if a modeler accidentally types a comma twice while
putting in vintages: 1,2,,3,4.

This was a forgotten addition originally, and without it, the following
if-check for no vintages is always false.  This wasn't caught because of
the front-end layer, but now it's fixed in the backend.  Test for this
following shortly.
Correctly convert to an integer on save.

If someone were to instantiate an Analysis in a REPL or in code, and for
some reason set period_0 or vintage to a non-integer, the .save() call
is not enough to convert that instance's period_0 or vintage to an
integer.  New copies obtained from the DB will correctly be integers,
but not this original.  For example, /before/ this commit, this might
happen:

    >>> a = Analysis()
    >>> a.name = 'Some Name'
    >>> a.description = 'Some description'
    >>> a.global_discount_rate = '0.05'
    >>> a.period_0 = '1.4'
    >>> a.save()
    >>> a.period_0
    1.4

!!! That should be an integer!  Since the DB just silently converts it
to an integer, things are mostly hunky dory, but this view is now out of
date:

    >>> b = Analysis.objects.get( pk=a.pk )
    >>> b.period_0
    1

Clearly the DB saves it correctly.  After this patch, the value for
period_0 and .vintage now update on save:

    >>> a.period_0
    1

Phew!  Not a big bug, but hopefully preventing a hapless command liner
from themselves ...
Some basic unit tests for VintageForm.
Update tests based on now correct code.
Third times the charm.

Though unlikely, we can't round because that changes negative numbers.
That is:

    round(-2 + .5) = -1, not -2.

I could be smarted about it, perhaps with an absolute, but at this point
it's not worth it.  Just int(float()) it and be done.  Programmer,
beware!
Update tests one more time.

The underlying code this tests not just does a straight int() call,
rather than attempting to deal with the spurious and unlikely use-case
of (for example), 1.999999999999998 occuring instead of 2.  Thus, 5.85
should now be 5, as int(5.85) just truncates the decimal portion.
Actually call clean() before save.

This is one where functional testing would be more appropriate as the
issue is interprocedural.  Perhaps I'll write that ...