Reviewed proj4js projection definitions.

From what I've learned so far is that proj4js transforms fine inbetween
EPSG:3396/7, EPSG:31467/8/9. What spoiled the transformation was a questionable
'towgs84' that I've mistakenly quoted from QGIS. It is left out anywhere else
though, e.g. in http://spatialreference.org/ref/epsg/3397/proj4/ etc.
Transforming back and forth still shifts coordinates by 7mm but I cannot care
less. WGS84 on the other hand is off SW by 184m in QGIS and N by 65m in ArcGis.
What leaves me to the conclusion that neither one of these transforms well to
it and I shouldn't bother calibrating proj4js to either one.
So I'd just transform to plain WGS84 now and adapted the offset correction to
the new projection definitions. It didn't make sense to import data in WGS84 in
the first place, but if it's from EPSG:3397 or EPSG:31469, coordinates are more
aligned than before.
Absorbed coordinate offset into utils/proj4().

I can't decide if either QGIS or ArcGIS transforms to WGS84Vcorrectly, so I
just refrain from importing any data in this crs, as I always did before. The
offset is now neatly cached into the views and doesn't have to be added at
runtime anymore.
The function has the same effect as to require('./proj4') directly, but if the
signature proj4(definition) is used, it wraps forward/inverse and applies the
coordinate offset from script/google.maps.js.
Replaced last occurrence of a $.html() on user data.

This continues a0c857237, and it just constructs a $('<th>') with $.text() and
then inserts line breaks using its inner HTML.
Used variadic form of $.append() where it makes sense.

I should read the documentation more thoroughly.
Reviewed proj4js projection definitions AGAIN.

Ok, now it seems that at least QGIS and proj4js have the same understanding of
the towgs84 parameter set. It just should have been added to all of my
projection definitions, because QGIS seems to apply it all the time.
Coordinates remain displaced to Google Maps aerials, but not as far as before,
meaning that lib/proj4() has to stay.
On another positive side note, the shift in exported coordinates reduced to
0.7mm. I attribute this to coincidence or something.
Added EPSG:31495 as it's identical to EPSG:31469.
Explained that ArcGIS has unsafe WGS84.