Reduce log size to 200, on old devices as full log can take 5 seconds
for screen to load
The cell scanning code was split to remove wcdma scanning on Fennec due
to an older API level on Fennec. This is no longer the case.
For screens less than 500px wide, allow higher zooming on the map. On the
320px screen I tested, full zoom out was 20x20km, previously it was
5x5km
On 400 error, print the stumble to the log without truncating it
Reducing log spam, need to review with @crankcoder to see if any of
these need keeping
Merge branch 'dev' of https://github.com/mozilla/MozStumbler into less-log-spam

Conflicts:
	android/src/main/java/org/mozilla/osmdroid/tileprovider/modules/TileDownloaderDelegate.java
Coverage url was accidentally made non static in a previous change. The
means it gets re-inited more often, and more logging errors if there is
no network. Also wrapped the logging for this in debug-only.
Log Activity truncation: only count longer lines towards the 30 lines
before truncation.
Merge pull request #1114 from garvankeeley/reduce-log-size

Reduce log size to 200, on old devices a full log can take 5 seconds for screen to load
init checkin of a tile file which also contains header data
Added test and code for new SerializableTile fileformat to hold tile
data as well as an arbitrary number of headers
Added code back to get a full stack trace on Error instances, but not Exception instances.
Dropped the unused getDrawable(InputStream) method and added a System.gc() prior to decoding bitmaps in BitmapTileSourceBase
dirty commit
comments on bugginess.
This reworks the LRUMapTileCache to use a proper LRU.

The capacity of the underlying LinkedHashMap has been modified to be 2x the requested capacity as there's a mismatch in meanings.

The callers is asking for capacity in terms of tiles, the capacity for a linked hash map is the # of hash buckets available which is a smaller number.

The final effect of this patch is that memory usage is pretty constant @ ~37MB on a Moto G with a 5x5 tile screen, but this adds significant flicker.

The upside is that this finally seems to fix the memory consumption error and no more OOM death.
More GC cleanups when swapping low/high res maps.

This prevents the swapping over hig/low res maps from consuming
~5MB per switch and fixes the flickering issue with tiles being evicted from LRU.

This should mitigate the memory leak mentioned at the end of
https://github.com/mozilla/MozStumbler/issues/1120
Comment updates to LRUMapTileCache and ExpirableBitmapDrawable
1121 - NPE due to calling newMLSPoint with a null point
This happens due to 400 errors in requesting MLS point. Which leads to the next question as to *why* we are getting 400 errors here. These should be logged already, so we should investigate.
Added tests and code to serialize tile to File objects.