Factory pattern added for using page objects.

The idea here is to provide a mechanism that instantiates page objects by using a simple factory approach. The idea for this is to allow code to take on a very common structure, making it easy to review and easy to build automatic checkers for. This approach is also nice for indicating workflows in a browser application.

There are two factory methods: on_view() and on().

The on_view() factory simply creates the page instance and uses the load() method to bring that page up in the browser. The on() factory creates the page instance but does not need to bring up the page in the browser since it's assumed the relevant page is already in view.
@abotalov 

Page objects do not store (or, I should say **should not store**) any state other than:

* Elements and subelements defined in the page object model
* other static page information, e.g. url, url matcher
* Behavioral helper methods which perform an action but do NOT persist page state, e.g. `fill_in_form(some_values)`

Page objects and their nested elements should never store actual state information of the page itself, e.g. the current text value of some element on the page.  Page state should _always_ be validated against the live page itself (and by live page, I mean the real, live page in the browser to which the driver is connected).

That being said, there is no benefit to instantiating page objects more than once, because once instantiated, their state is purely static in nature and all non-static state is provided by responses from the driver.  Instantiating a new instance of the same page object for every test simply consumes more CPU time and memory than using a singleton or page registry approach.