Location: use Location objects instead of doubles

**Note that this changeset is not finished yet, do not merge. I have opened this pull request to get your early feedback. I will append future changes here.**

This commit replaces most double-typed locations with Location objects. Most important exception is network-level messages. String representation of the new Location objects remains unchanged (i.e. textual double representation).

The general idea is that only very low-level parts of the code have to have knowledge on the type (and peculiarities) of the actual location encoding, most parts can do with some simple operations on locations (e.g. distance, isValid).
Those operations are now encapsulated in the Location objects, instead of providing them as static operations on doubles. The old static Location methods are converted to work on Location objects, and are deprecated for future removal (this causes a lot of warnings at the moment).

This changes mainly serve to prevent errors in duplication of location logic. Apart from this, it may also serve as preliminary work for switching the internal representation of locations from doubles to longs, if that may be considered necessary at some point.

To do:
* documentation of introduced methods
* removal of deprecated static methods
It might be more suitable to discuss this on IRC, but I'll reply here anyhow.

> But that still means that every Location that is not a Valid is an invalid one.

Correct.

> I mean, at creation time we know whether a location is valid or invalid, right?
Also correct. That's why the static factory methods are provided, instead of the constructors: it allows us to determine whether to return a `Valid` (soon renamed to `ValidLocation`) or just a plain `Location` (that would then be invalid).

> I don’t think it makes sense to have anything variable in a location that is known to be invalid because it will always react the same way, won’t it?

`Location` serves a double purpose: its direct instances are invalid locations (hence the lack of member variables!), but it's also the superclass of `Valid` (with all the member variables: `loc` and `hash`). So as far as types go, all valid locations are (indirect) instances of `Location` as well, but `Location` by itself has nothing variable.