Rework WebViewController so it can be instantiated with a pageName

This makes it so the WebViewController can be used without needing to
subclass it; the goal being that a WebViewController can be
instantiated by Calatrava whenever a custom UIViewController can't
be found.
Default to creating a WebViewController if no custom view is found

If the PageRegistry can't find a custom UIViewController implementation
when looking for a page by name, it will create a WebViewController to
display the shell page.

This change makes it so the iOS app will implicitly show the shell
views without any work from the developer. To use a native view, you
just need to create a UIViewController and the WebViewController won't
be used anymore.
Don't capitalize the page names that are stored

The handling of page name casing is somewhat inconsistent, and this
causes issues when we pass the name directly to the WebViewController.

The registry was capitalizing the page name, and the WebViewController
pageName method is used to call the window.pageViews.pageName.render
function; so when you pass the capitalized page name directly into the
WebViewController it ends up trying to call an undefined object on
pageViews.

We should probably normalise all names to a standard format, but until
then this commit changes it so we don't touch the casing apart from
when we try to find the ViewController by name.
Be safer about executing javascript in the web views

Whenever javascript is executed in the web views, namely to render
views or fire events, there's the possibility the call might throw an
exception; when an exception is uncaught, the whole javascript
execution fails and the app becomes useless.

This change wraps every call to the javascript runtime in a try...catch
block and returns any unhandled exceptions to the caller. If the result
contains an exception, it's rethrown as an NSException.
Merge branches 'default-webview' and 'ios-javascriptsafety'