various tweaks & fixes

Mostly for
https://github.com/libgdx/libgdx/issues/2359
https://github.com/libgdx/libgdx/issues/2524
https://github.com/libgdx/libgdx/issues/2441
https://github.com/libgdx/libgdx/issues/2436

While I agree they can be considered noise with no semantic value, they indicate that the class *is* in fact generic, otherwise it's visually identical to any other class. I wouldn't have any problem with internal lib code choices; the main problem with this approach is that when using a libGDX-based projects *and* wanting to have rawtype warnings generated for the non-lib-side code (and I assume that's the Java standard, at least Bloch, Oracle's Java tutorials & default settings of IDEs), the classes overriding libGDX has to adhere to libGDX method type signatures, generating the warnings themselves. For private or package private fields/methods I don't see a slightest problem with `Class`, yet for protected and public fields it makes inheritance without code smells impossible.

Still, I can agree it's an arguable case, mainly because the generics themselves sometimes produce nasty problems with erasures etc, so if you're confident the API has to stay non-standard (Bloch, EJ2nd, items 23/24), I can only agree with it. It's just that while I disagreed with standards on many occasions, with every passing month I'm more and more convinced they are the way to go, due to POLA. For seasoned Java programmers, a JLS-compliant & Bloch-compliant lib code is much easier to use, mainly because they use it everyday.