Memory leaks, the ticket to end all tickets

[spyhunter99]

This ticket shall cover the multitude of memory leaks within osmdroid. These leaks (typically) only occur when destroying and creating the mapview multiple times in a session. Related tickets #57 #328 #318 #283 and probably many others.

I've been silently working on this issue for a few days. Here's a few notes on the issue.

The AS 2.1 and newer apparently no longer has the memory and cpu telemetry in the IDE. Grrr
Finding root causes of leaks is a real pain with lots of guessing and checking
Leaks behave differently on different versions of android.
Many of the leaks, but not all, are really on present issues for those that run osmdroid in a fragment
Many of the leaks only affect the sample application. But if the sample app "is the right way do use osmdroid", then we should definitely fix it.

To setup the test environment, I've been modifying the unit tests to run the same example fragment 100 times with memory counters on start and stop. I've also adding instrumentation to the aar library to keep counters of OOM exceptions, which is used to force and earlier termination of the tests. In the future, it may be useful to developers that use osmdroid to detect error conditions. Currently, many of the internal error states simply are not accessible programmatically anywhere.

This ticket also reduces the number of static variables used within many of the overlay classes to enable those variables to be GC'd. It also covers the LRUCache which doesn't get purged when the mapview is destroyed, which is clearly a problem.

More information to come

[spyhunter99]

near ready for merging