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.
I would agree that Context is a more appropriate term here, as you are setting the context of the current test with regards to the active page that the Driver has loaded.  With that in mind, `DriverContext` may be a more appropriate term, since you are in fact storing the currently active context of the Driver and is unrelated to the state of any given Page.

IMO calling it a Factory because it calls `#new` on the supplied Page class does not classify it as a factory, because if you apply the SRP to the `Factory` class as it stands, we will observe it's primary responsibility is to set the context of the driver.  Its specific intent is not to generate new Page objects based on a generic base Page class or classes.

The expressed intent of the DriverContext in this case by calling `SomePage.new` is in fact to retrieve that specific page from a Page Registry.  See below.

##### Concrete Page Classes as a Page Registry

**TLDR;** The composition of concrete SitePrism::Page class definitions in a project implicitly comprise a Page Registry, wherein each Page class is an entry in the registry.

SitePrism::Pages are implemented as concrete classes. As such, a Page Factory does not produce value as a Factory if it is used to instantiate specific named Page classes which already provide concrete implementations for the page object model of a specific page.  It is far more direct to simply call `SomePage.new`.  Take the following example:

```ruby
a = HomePage.new
b = HomePage.new
```

There is and never will be a difference in state between instances `a` and `b` of HomePage. All concrete SitePrism Page classes would function identically if the singleton pattern were applied to allow a single instance.  Similarly, Page classes would act the same as they do now if rewritten as static classes/modules rather than instantiable object classes (notwithstanding the obvious breaking changes this would incur to projects using SitePrism).

If we thus accept that the composition of our concrete Page classes comprise a Page Registry, then the `Factory`, or `DriverContext` is in fact looking up the desired page object from the registry and setting the context of the driver to that page.  The expressed intent of the DriverContext therefore by calling `SomePage.new` is in fact to retrieve that specific page from the Page Registry.

Given a concrete implementation of a PageRegistry where actual Page instances can be stored, indexed and queried would not modify the expressed intent of the DriverContext.