Move namespace from query param to path part

Per the accepted namespaces design, this PR modifies the URL patterns as follows:

| Action | HTTP Verb | Path | Description |
| ---- | ---- | ---- | ---- |
| CREATE | POST | /api/{version}/ns/{ns}/{resourceType}/ | Create instance of {resourceType} in namespace {ns} |
| GET | GET | /api/{version}/ns/{ns}/{resourceType}/{name} | Get instance of {resourceType} in namespace {ns} with {name} |
| UPDATE | PUT | /api/{version}/ns/{ns}/{resourceType}/{name} | Update instance of {resourceType} in namespace {ns} with {name} |
| DELETE | DELETE | /api/{version}/ns/{ns}/{resourceType}/{name} | Delete instance of {resourceType} in namespace {ns} with {name} |
| LIST | GET | /api/{version}/ns/{ns}/{resourceType} | List instances of {resourceType} in namespace {ns} |
| WATCH | GET | /api/{version}/watch/ns/{ns}/{resourceType} | Watch for changes to a {resourceType} in namespace {ns} |

The typical actor for the following requests are the k8s service or k8s admin as enforced by k8s Policy.

| Action | HTTP Verb | Path | Description |
| ---- | ---- | ---- | ---- |
| WATCH | GET | /api/{version}/watch/{resourceType} | Watch for changes to a {resourceType} across all namespaces |
| LIST | GET | /api/{version}/list/{resourceType} | List instances of {resourceType} across all namespaces |

The legacy API patterns for k8s are an alias to interacting with the *default* namespace as follows.

| Action | HTTP Verb | Path | Description |
| ---- | ---- | ---- | ---- |
| CREATE | POST | /api/{version}/{resourceType}/ | Create instance of {resourceType} in namespace *default* |
| GET | GET | /api/{version}/{resourceType}/{name} | Get instance of {resourceType} in namespace *default* |
| UPDATE | PUT | /api/{version}/{resourceType}/{name} | Update instance of {resourceType} in namespace *default* |
| DELETE | DELETE | /api/{version}/{resourceType}/{name} | Delete instance of {resourceType} in namespace *default* |

Good suggestion, I will move it into ```registerResourceHandlers```.

```Event``` objects are namespace-scoped today.  

The only outlier is ```Minion```.  I had originally put a flag on ```RESTStorage``` to control if the resource was namespace scoped to control registration of the additional routes, but the negatives for that pattern was a complication of client side logic for how to build URLs to generic resources.

If I am interacting with a namespace and want to know the set of minions that my work can be scheduled on, it seems sensible to call ```/ns/myspace/minions```.  If that result set is the same as the global pool of minions returned at ```/minions```, its perfectly fine in my view.  In the future, if we have dedicated minions for a namespace, then that operation can return a different result.