Revert "SDL2: Apply PAULSCODE-specific customizations (does not link)."

This reverts commit e175994bfc4b471c993a95749332163c51877da8.
gles2rice: Fix #defines to work with pristine SDL 2.0-release.

SDL 2.0-release no longer uses the SDL_VIDEO_OPENGL_ES2 macro (though
it still works properly inside SDL for backwards compatibility).  So
we update the macros in rice accordingly.  No customization of SDL2
necessary for out-of-the-box building.

I'll submit a pull request upstream this week.
SDL2: Exclude android-project example code.

This stuff is great if you're starting out with a hello-world app or
just want to port an existing SDL app to Android quickly.  I.e. an app
where SDL provides the central unifying platform/engine on which the
app is built.

But for our case it actually complicates more than it clarifies...
Mupen64Plus is the fundamental unifying platform/engine and SDL2 is
essentially just a library of platform-agnostic multi-media utilities.

Removing it for two reasons.  Avoid future red-herrings, and eliminate
any confusion when a new developer imports the mupen64plus-ae repo into
their eclipse workspace.
SDL2: Exclude non-essential documentation.

To keep things clear and avoid confusion, I'm excluding all documen-
tation that's not relevant to our situation.
 - Stuff for other platforms (iOS, pandora, etc.)
 - Android example documentation (since I excluded the example itself)
 - Non-android makefile/script/config stuff

I tried to keep all the essential stuff (licenses, credits, about, ...)
but if I cut something I shouldn't have, feel free to push it back in.

At the end of the day, the files in our SDL2 directory are a strict
subset of the complete upstream SDL-2.0-release tag.  Our files and
directory structure match the upstream version exactly.
Merge branch 'sdl2-revert-and-prune'
eclipse: Remove project metafiles *SEE COMMIT MESSAGE*.

These files don't belong in the git repository since they are user-
specific and subject to change based on eclipse version.  After merging
this commit, you will need to regenerate your own version of these
files.  Here's how:

 1. In eclipse "Delete" the project from your workspace (but don't
    delete the actual files)
 2. Close eclipse and manually delete the above three files (if they
    aren't already)
 3. Open eclipse and File->Import... "Existing Android Code Into
    Workspace"
 4. Right-click project->Android Tools->Fix Project Properties
 5. Right-click project->Android Tools->Add Native Support...
      a. Enter name "Dummy" and click Finish
      b. Manually delete jni/Dummy.cpp
 6. If you want multi-core compilation (dramatically faster builds),
    go to Project->Properties->C/C++ Build
      a. Uncheck "Use default build command"
      b. Set build command to
           ii.  "ndk-build -j3" if your build machine runs 2 cores
           i.   "ndk-build -j6" for 4 cores
           iii. "ndk-build -j12" for 8 cores
           iv.  etc.
 7. For auto-formatting the Java code (ctrl-shift-f), be sure to
    import the formatting settings located in ./doc/config_files/

When this is all done, the C/C++ indexer should work properly and
resolve #includes correctly.  The drawback (besides the initial
recreation) is that you'll have to redo this process every time you
jump to an old revision where the files are tracked, then jump back to
the newer revision.  The easy solution to this is to just back up your
untracked files and restore them every time git deletes them after the
reset.