Enforce namespace unique constraints

This is the update to actually enable namespace support.

At the moment, I pass a namespace as a query parameter in order to support namespace scoping on the v1beta urls.  Once v1beta3 lands, I will modify to pass namespace in the path.  Note the client libraries were modified to make this easy to do, so should be a trivial change once ready.

I broke the commits into logical sections to improve readability.
```
Is there a reason why this function takes an api.Context? That is for tracking client requests server side. There is not much sense forcing clients to use it, no? 
```

If you just think about the kubecfg client or the end-user of kubernetes, then sure, you tend to work in a single namespace, and this argument holds.  In fact, its how I first wrote the code, but if you take a step back, you realize the majority of our existing clients are server-side and need to operate across namespace boundaries to perform their operation.  It then becomes a matter of wanting to make it easier for those clients to operate.

The replication-controller and scheduler both follow a similar pattern:

1.  initialize the daemon with an interface X that is subset of kubeclient
2.  run a sync loop
3.  List/Watch over all name-spaces using X to resource type Y
4.  In response, do some series of CRUD operations in Y.Namespace

In OpenShift Origin, we have a similar pattern for build-controllers and deployment-controllers.  I suspect others may choose to write plug-ins that follow the same convention to meet a particular need.

If we kept context on Client as a means of passing namespace around, you are left with the following when looking at the above style-use case.

A. Create new client objects when you change namespace boundary
B. Require the ability to mutate a context on a client interface

(A) seems like an anti-pattern when its an obvious control loop in our internal usage of Kubernetes to require so many throw-away clients when we have callers that work in multiple namespace boundaries.  

(B) has issues with concurrency because we share the same client, and so we would need locking, and things get ugly quick.

That left me with (C) pass context as argument - which lets me reuse the client object, and keep clean enough reading code after actually writing all the other options for callers that work on resources across namespace boundaries.

As for this particular function taking a api.Context object instead of a string, it actually keeps the LIST/WATCH operations clean when working in the no namespace-boundary versus passing the empty string as input around.