Migrated script from index.html to script/login_bar.js
Removed <form> being nested inside <div>.
Applied small improvements to replicator.html.

- disabled submit button while http post is pending
- added login bar from index.html in case local accounts have been set.
Fixed misspelled query introduced in 389b4dc.
Removed Apache Licence.
Removed jquery-1.6.2.
Removed one typeof(obj)=="array".

I most ceartainly learned this from COBRA.
First draft on Geo information document structure.

Here it goes:
- I stick to GeoJSON because it is the GIS json spec (hooray) and GeoCouche's
  spatial indexing relies on it. If I have to switch to GeoCouch because of low
  performance, I don't need much extra work.
- All GeoJSON is stored as object named "GeoJSON" in doc.
- I don't use GeoJSON's "Feature" type to store non-GIS properties. Properties
  are stored as doc members (raw json looks better this way).
- Sweet: bbox is computed in map.js to take advantage of CouchDB's view cache.
  Also this property is part of the GeoJSON spec and used by GeoCouch.
- Still need to decide on a coordinate system. However, I can convert between
  WGS84 and Gauss-Krueger in this view without much performance loss.
- The field "GeoJSON_clone":doc_id reuses an existing GeoJSON of the doc id it
  points to. I've intended this to be different from a linked document (as in
  _list/tabulate).
- Of course "GeoJSON_clone" and "GeoJSON" are mutually exclusive. Also I say
  that there should be no 'stand-alone' GeoJSON; documents should always have a
  type because I don't like GeoJSON to be uploaded without any purpose or
  meaning or description.
I like how map/reduce is still able to compile GeoJSON and properties despite
its limitations on value complexity. Reduce lacks rereduce, so it might not yet
work for larger document collections.
Solved error message of reduce output growing too complex.

We only need to reduce over equal GeoJSON ids. Thus if group_level=0, we end up
with everything and CouchDB complains, because our programming sucks. The
solution is to return null if more than one key was found. I still have to tend
to the rereduce scenario.
Restricted docs to have either GeoJSON or GeoJSON_clone.

As discussed in b0cfd5, both at the same time make no sense.