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
The raison d'être of `Location.Valid` (or whatever its final name will be, it does not have to be a nested class) is to actually be used (almost) everywhere and provide guarantees about the validity of the value, so we don't fail in the middle of a method that only makes sense on valid locations, but accidentally passed it an invalid location. If we'd use `Location` everywhere, we'd always have to use `validated()` before distances etc. can be computed, or will lose the aforementioned guarantees.

`Location.INVALID` is merely an optimization: all invalid locations are equal, so we don't need multiple objects for that. Added bonus is that one can use `x.isValid()`, `x instanceof Valid` (not recommended) and `x != Location.INVALID` interchangably. The existence of the constant `Location.INVALID` has nothing to do with the existence of the class `Location.Valid`, although I see how their naming may trick one into thinking the opposite. `Location.INVALID` can (and should) never be possible to assign to a variable having the "always valid" type (currently `Location.Valid`).
Now I think of it, we might as well remove `Location.INVALID` (or keep the optimization, but make the constant private). External code should then use the provided `isValid()` or be prepared to catch an exception.