JSON Schema changes for RCv3 interface.

# Tasks:
- [X] Add rackConnect attribute
- [x] Port is not used by rackConnect.
- [ ] Validation from RCv3 team that we're building the right API

The part where we orchestrate the API is tracked via #728.

# API Reference docs
RCv3 API: http://docs.rcv3.apiary.io/
CLB API: http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/POST_addNode_v1.0__account__loadbalancers__loadBalancerId__nodes_Nodes-d1e2173.html

# CLB payload example:
```
                "loadBalancers": [
                    {
                        "loadBalancerId": 2200,
                        "port": 8081
                    }
                ]
```

# RCv3 payload example:
```
                "loadBalancers": [
                    {
                        "loadBalancerId": "d6d3aa7c-dfa5-4e61-96ee-1d54ac1075d2",
                        "rackConnect": True
                    }
                ]
```

The rackConnect attribute being true signifies that we're talking about RCv3 (which not all users have access to -- requires customer setup).  If it's not there, we're talking about CLB.

Note that the CLB loadBalancerId is an integer and there needs to be a port.  The RCv3 payload uses a loadBalancerId that's a UUID (they call it a load_balancer_pool instead) and doesn't require a port.
If this is a boolean value, should the value be constrained to `True` only (e.g. disallow `False`?)  Since `False` wouldn't make sense in this context, and it's disallowed for CLB's.

I generally agree with @lvh about type, though, and that would bring the load balancer blob more in line with the launch config schema.