front: Remove unnecessary Java loading of native libraries.

The core loads and unloads the plugins automatically from the native
side, so there's no reason to load them here.  Loading from Java is
actually contributing to the lifecycle issues, because it prevents the
core from actually fully unloading them when the emulator shuts down.

For now, we still load the android-input plugin from Java, since we
initialize it using Java methods.  We can change this later if we want,
but for now it doesn't cause any problems.

A goal in future commits will be to eliminate the Java loading of the
front-end, core, and SDL libraries as well, so that their static vari-
able initializers will be invoked when relaunching the emulator.

Also removed the CoreInterfaceNative library loading wrappers.  If
exceptions are thrown, we have bigger problems to deal with and we
shouldn't just brush them under the rug.
build: Remove unnecessary linkages to shared libraries.

The core does not need to be linked with the ae-bridge because it does
not invoke any ae-bridge methods.

None of the plugins needed to be linked with the core because they do
not invoke core methods; they merely handle callbacks.

The front-end does not need to be linked with the core because it dyn-
amically loads the core library at run-time.
ae-bridge: Remove ae_bridge_main from front-end.

I had tried putting this into ae_exports before and failed.  Didn't
realize it was just a function visibility issue.  Helps to consoli-
date the bridge and keep the build simple.
ae-bridge: Remove sdlQuit function (use emuStop instead).

Calling the core command (emuStop) is the most direct way to exit the
core's main loop and is the approach used by the upstream ui-console
(what we call 'front-end') library. Calling sdlQuit is just a round-
about way of achieving the same thing and is not used anywhere else.
doc: Added NVIDIA notes on lifecycle management (really good read).

From Tegra developer website.
front: Completely rewrite GL context management in GameSurface.

Contexts and surfaces can be re-used and re-bound if possible.  These
capabilities aren't being fully exercised... yet.
front: Wire up new SDL2 destroy gl context method.
front: Added more lifecycle callbacks and logcats for GameActivity.
front: Make game lifecycle handling more robust.

The emulator should only be started when the activity is resumed, the
surface exists, and the window has focus.  These states aren't
guaranteed to change in any particular order, so we simply track each
one and try to change the emulator state whenever one changes.  To
keep this stuff clean, we modularize it into a separate class.

The new implementation makes a few lines in CoreInterface superfluous,
so we remove them.

Note: There's still some weirdness when you hit the home button or
receive a call, and then resume the app.  The next commit will change a
whole lot of stuff related to the issue, so there's no point fixing it
yet.
front/ae-bridge: Remove system.exit calls, use normal activity cycle.

NOTE: On some versions of Android, if you quit the game activity (to
the play menu) and then resume/restart the game activity, you will get
a segfault (hard crash) as the game activity starts up.

I am intentionally committing this to demonstrate the need for native-
side library loading and unloading.  If you load a native library
through Java's System.loadLibrary function, there is no way to unload
it later.  This causes problems if the native code contains static
variables with static initializers (which is the case for us).  On
subsequent launches of the activity, the old library instance is re-
used rather than reloaded, and the static variables are thus not re-
initialized.  Thus you cannot reliably restart the activity in a fresh
state.

To get around the problem, we must load and unload the libraries on the
native side using dlopen, dlsym, and dlclose.  For a great discussion,
see http://stackoverflow.com/q/10649119/254218

Upcoming commits will address this problem, but I wanted to commit this
version as a frame of reference for subsequent discussion.
ae-bridge: Load SDL/core/front-end on native side rather than JNI.

This allows us to unload the libraries when we're done with them. Which
allows us to properly re-initialize all native static variables through
their static initializers the next time the GameActivity starts up.

Some important notes I learned the hard way:

 - If we load ae-imports/SDL2/core/front-end from Java in addition to
   loading them on the native side, they won't actually be unloaded
   when the native side unloads them.

 - Moreover, if any libraries we load in Java have build/link dependen-
   cies on ae-imports/SDL2/core/front-end, then they will still not be
   unloaded properly in some Android versions.

So, we must never System.load the ae-imports/SDL2/core/front-end libra-
ries on the Java side, and the libraries we do load from Java must not
contain build linkages to ae-imports/SDL2/core/front-end.

A side effect of not loading the libraries from Java is that their
JNI_OnLoad functions are never invoked.  So we must manually do that
from the native side after dlopen'ing them.

Note: Depending on Android version, there may still be some issues
after waking from sleep and/or resuming after call/home button.  Unlike
the issues a few commits back, this is actually related to gl context/
surface reuse/binding, and slight lifecycle differences between Android
versions.
ae-bridge: Rename/rearrange some things for clarity.

May require you to clean-build.

No functional changes.  Just renaming and grouping some things for
consistency and parallelism.
ae-bridge: Rename header and clean up some includes.
ae-bridge: Remove obsolete do_Start hack.

This flag no longer does anything.  Because the ae-imports library is
dynamically loaded and unloaded, do_Start will always have a value of 1
when it is first tested in the while loop in the front-end main func.

Also, we removed the reset function from the mapping screen way back at
commit 0b5083a5c3effa5a82762c3d778b926339dbf543, so no one has been
using this function anyhow.
ae-bridge: Remove some more dead code.

Forgot clean this up in commit
316954b07b56eb2a55d5fed31bc856ee325446aa
front: Always load input-android, and load it Java-side exactly once.

Doesn't hurt anything to load this library, even if the core ends up
using the dummy input plugin.
ae-bridge: Remove unneeded declaration and cleanup comments.
ae-bridge: Remove onResize callback, move to native code.

For us, this callback has no effect on screen sizing, because it's
coordinated elsewhere between the core and SDL, and is specified dir-
ectly in the mupen config file.  The only reason we need this callback
is to initialize SDL's internal pixelformat state.  It's much cleaner
to just do this directly from the native side during the startup
sequence.  No need to involve the Java side or the activity/surface
lifecycle stuff.

Note that before this commit, the RGB565 SDL pixel format was always
being called, regardless of the user RGBA8888 setting.  I'm not sure if
the value matters much here; it just can't be the initial value
SDL_PIXELFORMAT_UNKNOWN.
ae-bridge: Check function pointers before invoking them.

During startup, it's possible for one thread to invoke a core method
before the library has loaded and found the function pointer.
front: Fix state machine for game lifecycle tracker.

A bunch of fixes rolled into one.  I had to be hit over the head to
realize there are only three states (not four) in the state machine:
running, paused, stopped.  No such thing as "started" without running.

So the fixes:
 - Transition to stopped ONLY when the surface is destroyed.  Android
   4.3 (and probably others) does not destroy the surface when the user
   presses the power button; it merely stops the activity.  If we stop
   the emulator onStop, then we have broken GL context stuff when the
   emulator starts running again.  That results in lock-ups, etc.
 - When starting to run, we either startupEmulator or resumeEmulator,
   but never both.  Before, we would resumeEmulator immediately after
   startupEmulator, which wasn't necessary and introduces a potential
   race condition later.  Though the race condition is currently miti-
   gated with the function pointer checks in the ae-bridge, it's
   better to just have the correct design to start with.
 - Clean up some internal variables, improve readability (e.g. the
   isSafeToRender function).