Javadoc improvements, switched from alphabetic to semantic ordering.
Disable Android GL error checking by default.
Reference the locally built jars rather than those in the Maven repo.
Added a test for some surface drawing routines.

This already illustrates that drawing a line with width > 1 behaves differently
on Java versus the GL backends.
Various OpenGL cleaning up and improving.

I started down the road toward adding Surface.fillPolygon and got sidetracked
cleaning a bunch of stuff up. Said stuff includes:

1. I switched everything to TRIANGLE_STRIP a while back, without thinking about
the fact that this relied on the ostensibly temporary circumstance that all the
GL renders flushed after rendering each quad. I started down the road toward
ditching the elements array entirely and just rendering one quad at a time (if
we're always just rendering 4 verts in a tri-strip and flushing, we don't need
the elements array).

However, I decided to hold out hope that one might actually get some mileage
out of rendering multiple quads at once (either by using the depth buffer and
sorting by texture, or by virtue of clever use of ImmediateLayer or structuring
a GroupLayer such that it contains all children that come from a single texture
atlas). So, I switched everything back to TRIANGLES, and bumped up the max
verts &c in Android and iOS to 32 quads.

The WebGL backend has an unfortunate wrinkle. Every call to drawElements
requires that the elements array be range checked (that means going through
each element of the elements array and making sure it references an element
that is "in bounds" in the associated vertex array). As you might expect, this
is crazy expensive. Browser try to ameliorate this by caching the check, but if
you change the array on every call (by using subArray), then you subvert their
attempts at caching. Thus, if we allowed the WebGL backend to attempt to send
multiple quads, but 99% of the time just send one and use a subArray,
performance would suffer. I don't know by how much, I don't have time to run
experiments.

Given that WebGL is forced to ship a single quad at a time to OpenGL, it would
be nice for the GLContext and GLShader abstractions to allow WebGL to use
TRIANGLE_STRIP and avoid the use of elements altogether, which leads me to my
next change.

2. I added GLShader.addQuad, which adds a whole quad at once to the current
render operation. AbstractGLShader (which all backends extend) just breaks this
down into the same series of beginPrimitive, addVertex and addElement calls
that used to be done manually, but it's possible for (say) the WebGL backend to
override this call and create and ship a TRIANGLE_STRIP-based quad directly. I
did not actually make that change, as I'd prefer it to be accompanied by some
sort of performance experiment that demonstrates that it's faster. Regardless
of whether it's faster, addQuad also now avoids calling local.m00(), etc. four
times when adding each quad, and rather extracts those values into locals once
and uses them for the four addVertex calls. This is a win on all the other
platforms, which may not have the most sophisticated inliners in the world.

Relatedly, it kills me that we ship four copies of the 6-float transform matrix
to the graphics card for every quad. We send 16 floats of vertex/texture data
and 24 floats of transform data that could be 6 floats. I am not thinking of a
clever way to share the same transform matrix for four vertices, and any sort
of multiple array shenanigans that I might perform would probably end up being
slower for reasons byzantinety, but my craw remains stuck into.

3. I nixed GLContext.fillPoly, which has always been full of incorrectness and
only ever used by Surface.drawLine. It's replaced by GLContext.fillQuad which
works as advertised for all callers. In the process, I made Surface.drawLine
honor image fill patterns, which it previously failed to do.

4. I added GLShader.addTriangles, which will provide the basis on which
Surface.fillPolygon is eventually built. However, I have to decide whether I
want to just expose this (or its moral equivalent) directly to Surface, or
create a Polygon class that handles the tessellation into triangles for you.
The problem with the latter is that tessellation is expensive, so I'd either
have to make Polygon immutable, or make it invalidate and regenerate its
tessellation when its vertices change. This is problematic because games that
want to render polygons probably want to make clever blobs that ooze and flow,
or do other tricksy things. To do that efficiently, you want to be mutating
your tessellated polygon mesh directly. You also might want to do interesting
things with the texture coordinates, which I don't think would translate nicely
into any sort of sane Polygon interface. I guess I've just convinced myself to
expose fillTriangles() and call it good.