Refactor Android API into immutable state classes

[ljbade]

While working through MapView for #2002 I have come to the conclusion (and @tobrun agrees) that the code has grown in that single file to a point where it is getting harder to manage.

In #2002 I am trying to fix that up a bit and move functions back into logical groups and sections, but @tobrun suggested the approach from Clean Code by Robert C. Martin and split MapView up into separate classes that look after their own bits.

If you look at the Google Maps Android API, you can see they follow a similar approach by using immutable classes which we would be wise to follow. This enables the bonus that their classes are Parcelable which makes things like storing the map state a lot easier.

We are likely going to follow the immutable pattern with @1ec5 Camera API, and the existing Annotation API is almost following the same pattern.

I reckon we should hit this in our next major Android milestone.

/cc @mapbox/mobile

[tobrun]

To clarify, Robert C. Martin vision boils down to the SOLID principles.

[bleege]

Sounds good. MapView has gotten HUGE. Let's put this on the 0.2.0 roadmap for now.

[tobrun]

This issue is outdated and not that actionable anymore.
The general idea behind this issue will be picked up in the 4.0.0 release.
In that release we are focussing on parity on Google Maps and making our architecture more testable.