Breaking changes in view model binder callback functions.

View model binding callbacks have changed.
beforeBind => binding
afterBind => bindingComplete

Improvements in the view model binder's core functionality allowing
skipping of the apply bindings call as well as passing instructions
along to the view model binder's beforeBind and afterBind hooks.

Added a missing view id to the internal default message box view.
Prepping for typescript definitions...
Improvements to the viewModelBinder...

...to allow get/set of binding instructions.
Fixed potential double activation...

..which would happen when views were being cached and when an instance
was being re-bound against a new view.
Returning a promise from activate is NO LONGER REQUIRED...

...we have made some core improvements in the composition infrastructure
that no longer require returning promises to Durandal for async actions.
Previously, not returning the promise would break ko.observables. This
is no longer the case. You may still wish to return the promise from
activate to halt binding pending your service request...but it is not
required anymore.
Removed all knowledge of view caching from transitions.

This makes transitions simpler and isolates the knowledge of view
caching inside of the composition module.
Implemented fine grained control of view caching.

From the modules binding callback you can now return an object with a
cacheViews property set to false to tell the composition system
(previous configured with cacheViews:true) to not cache the view for
this particular module in the DOM.
The plugins api has changed to support multiple locations.

Instead of setting a plugins property on the app, you call
configurePlugins. The first parameter is the same as before, an object
with a property per plugin, optionally specifying its confguration. The
configurePlugins API has an optional second parameter which you can use
to specify the baseUrl to load the plugins from. By default it is
'plugins/'
Added router.navigatingBack to the main router.

As it turns out, there's no way to tell whether or not the user
navigated back or forward. This property is a best guess. It will be
true if the interaction did not happen through a link or navigate api
call and if the previous and new route fragments do not match. Note, we
cannot tell the difference between forward/back button presses. Also, we
cannot tell if someone typed a new url in their browser as opposed to
using the forward/back buttons. In both of these cases, the router will
have navigatingBack true.
Explicit queryParams prop added to router instruction...

...for easier use within guardRoute.
Made the router work correctly with/without trailing slashes.
Fixed a composition glitch with splash screens.
Fixing up some error logging in activator.
Fixed a bug in configurePlugins

...which prevented making multiple calls to the API.
Activator and Router now understand cancellation data.

-As a result, you can redirect from canActivate. To do so, return an
object to the router like so { redirect:'#/your-hash' }
Experimental ko override to enable better async programming.
Fixing an activation bug related to routers...

...activation of the same instance, but with different parameters did
not work.
Updated typescript def header.
BREAKING CHANGE to Lifecycle

-viewAttached/attachedToParent renamed to attached
-detachedFromDocument renamed to detached

Enabled composition.addBindingHandler to take an optional init options
factory, for complex deferred binding handlers.