SSP-2004 Fix MAP event handler registrations

MapViewController seems to have been clobbering existing application
event handlers before adding its own. It was doing this at least in
part because the SSP ApplicationEventsController API only allowed one
listener per event. This mostly worked except for the case of the
'toolsNav' event for which we do have other important event listeners,
notably the listener that expands and contracts the search/caseload
panel. So you'd get the expected expand/contract behavior until you
navigated to the MAP tool, then MAP's 'toolsNav' handler would replace
the 'standard' one, and the expand/contract behavior wouldn't work
until circumstances conspired to re-register the "standard" handler,
which usually only happened when reloading the browser. Other events
just happened to not exhibit this behavior because there weren't other
listeners.

The workaround for 'toolsNav' was to remove the handler clobbering code
and drop down below ApplicationEventsController to the standard Ext.js
Application API to register the MapViewController handler while
preserving the registration of the handler already added by
SearchViewController (which actually implements the expand/collapse
behavior).

This patch is conservative in that it doesn't try to fix the
registration of events that aren't currently broken (basically
all events except 'toolsNav'), but because event registration is a
first-one-wins situation, expect unreliable behavior in the future
should we introduce any other components that rely on the same
application events:

  toolsNav
  personNav
  personButtonAdd
  personToolbarEdit
  personButtonEdit
  personButtonDeleted
  retrieveCaseload
  personStatusChange

I think the solution for this problem is at least two-fold...

  1) Change the ApplicationEventsController API to stop
     silently dropping event handler registrations. Nobody
     will ever expect that behavior. A "replace" operation
     is fine, but not a "set unless already set".

  2) Refactor the event model into before*, on*, and after*
     events for each change to be broadcast. 'before*' events
     are intended to offer the option of canceling the other two.

registration function with "set unless already set" semantics. I.e. the
only reason you'd want that would be to make sure a privileged
listener gets veto power, but you can get the same thing with events
that better reflect change lifecyles without creating the fragility
we're seeing in this current issue.

This patch also moves all handler de-registration to destroy() and
properly scopes the de-registrations to make sure we're only cleaning
up handlers we registered and to make sure we actually do clean up
those registrations. This is intended primarily to address the
'toolsNav' event handler clobbering problem. It might also have an
incrementally beneficial impact on memory management since MAP
components can now be GC'd immediately upon navigating away from MAP.
But I don't think the original factoring was actually causing the
memory leaks reported in the field because navigating back to MAP
would again clobber any event listeners previously registered.

It's worth noting that the code doing the clobbering doesn't behave
as expected given the Ext.js docs
(http://docs.sencha.com/extjs/4.1.0/#!/api/Ext.app.Application-method-removeListener):

  me.appEventsController.removeEvent({eventName: 'toolsNav', scope: me.application});

Which is handled by:

  removeEvent: function( args ){
    if ( this.getApplication().hasListener( args.eventName ))
    {
      this.getApplication().removeListener( args.eventName, args.callBackFunc, args.scope);
    }
  }

The Ext.js docs (and code, as I read it) strongly suggest that the
absence of a args.callBackFunc here would result in a no-op. But that
seems pretty clearly to not be the case.

On the non-conservative side, this patch also simplifies
MapViewController event handler callback scopes to be less indirect.
In no case do we need the callback scope to be the application so it is
now always the current component (MapViewController).