Add a resource fit predicate.

Not linked into any scheduler yet.
I think it does matter.

Capacity and Limit are the same thing from different perspectives.  A node has capacity into which pods can be placed.  Does a pod have capacity into which containers can be placed?  How is capacity ever different from limit, except in the words you use to describe it?

    * When we ask a node what is available, we get capacity and max.  request and limit are nonsense.
    * When a user requests resources they can spec a request and limit.  capacity and max are nonsense.
    * When we ask for pod status we get request and limit and max.  capacity is nonsense or === limit.
    * When we ask for container status we request and limit and max.  capacity is nonsense.

As for new types, we *can* reuse the same structure for all places where we want to talk about resources.  But this runs the risk of accidentally carrying invalid data around.  For example, we need to remember to clear capacity and maxusage(peak?) when an API call comes in to create a pod.  It also makes the types.go file a lot less self-documenting (and we know how up-to-date our docs are).  We have this problem elsewhere, and we DO NOT do an appropriate job of input filtering.

To me, this still smacks of forcing column-major order on something that should be row-major, but I lost that battle.