Decouple GLES20RecordingCanvas lifetime from GLES20DisplayList.

Decouple GLES20RecordingCanvas lifetime from GLES20DisplayList.
Bug: 5062011

Previously, each GLES20DisplayList would hold onto an instance of
GLES20RecordingCanvas.  In turn, each GLES20RecordingCanvas
held onto an SkWriter with a 16Kb buffer along with several other
objects.  With one display list per view and hundreds of views,
the overhead could add up to a few megabytes.

Ensured that the GLES20RecordingCanvas is reset as soon as
the display list has been constructed, thereby promptly freeing
the 16Kb buffer.

Changed GLES20DisplayList so that it acquires a GLES20RecordingCanvas
from a pool as needed and recycles it when done.

Removed some dead code and cruft related to the construction of
GLES20Canvas objects in general.  Some code was written with the
assumption that the underlying renderer object could change
behind the scenes or might be lazily constructed, but that isn't
actually the case so we can simplify things.

Removed an unnecessary weak reference from GLES20DisplayList
to the View.  It isn't actually used anywhere.

Fixed a bug in GLES20DisplayList where isValid() would return
true while the display list was being recorded.  This is incorrect
because the native display list might not actually exist.  Worse,
even if the native display list does exist, it is stale and
potentially refers to old Bitmaps that have been GC'd (because the
mBitmaps list was cleared when recording started).

Change-Id: Ib12d5483688cb253478edeb0156d34c476c2566b