Proposal for solving "crossing date line geometries" problem

**Warning: This is full R&D, POC, not mergeable at all in this state!**

This follows the [discussion we had](https://github.com/Leaflet/Leaflet/commit/f5cfab73a19e8976289b85cce8a6e04a66fe6c00#commitcomment-2386191) about longitude wrapping and geometries [crossing date line](https://github.com/Leaflet/Leaflet/issues/82). With the 0.5 release (\o/) I've started thinking about this again.

As you already know, ***my*** opinion is that removing wrapping from `L.LatLng` was a good move, but removing it from default Leaflet behaviour was not such a good one.

My main points are:

- this breaks consistency with other GIS, like PostGIS (which doesn't accept longitudes over 180 when in  geography mode)
- this doesn't totally solve the "cross date line" problem

I mean, for example, just trying to display a polygon around New Zealand will not give expected results. Say:

```
        L.polygon([
            [-40, 176],
            [-45, 178],
            [-46, -178],
            [-40, -175],
        ]).addTo(map);
```

This will result in a huge polygon crossing the whole world, instead of a small one crossing the date line.

So thinking about this, I went to this point:

- Leaflet **must** use acute coordinates internally, and **must** be able to expose them to third party GIS
- Leaflet *should* try to **display** things as close as possible as how *humans* expect them

In others words: *data* is for machines, *displaying* is for humans.

So I thought about some heuristical algorithm to determine where some ambiguous point has to be displayed.

This algorithm is very simple, but in the same time quite intrusive, and actually I don't fully like my current implementation, but here is what it looks like:

- when projecting a point, try to give a context to disambiguate
- this context is by default the map center
- and when displaying a path, use previous point of the path to contextualize the next one

And than you can successfully display the above Polygon. :)

As previously said, the actual implementation lacks of some refactoring, it's just a proof-of-concept. The aim is to continue the discussion, and not just complaining, also making some proposals ;)

So, when you have some time, I'd like your opinion on this proposal. Hence, if you think some point merit to dig in and not just everything has to be trashed, I can work on it to reach a satisfactory state.