VTEP binding deletion CLI

Makes VTEP and VTEP bindings aliased, and allows referencing them via
aliases for show / list / delete commands.

Sample command lines:
midonet> list vtep
vtep vtep0 name br0 management-ip 119.15.112.22 management-port 6633 connection-state CONNECTED
midonet> vtep vtep0 show management-ip
119.15.112.22
midonet> vtep vtep0 list binding
binding binding0 management-ip 119.15.112.22 physical-port Te 0/2 vlan 908 network-id bc3afc36-6274-4603-9109-c29f1c12ba33
binding binding1 management-ip 119.15.112.22 physical-port Te 0/2 vlan 439 network-id bc3afc36-6274-4603-9109-c29f1c12ba33
binding binding2 management-ip 119.15.112.22 physical-port Te 0/2 vlan 777 network-id bc3afc36-6274-4603-9109-c29f1c12ba33
binding binding3 management-ip 119.15.112.22 physical-port fakevm1_out vlan 0 network-id 7071b156-5f05-4d8c-8df2-3bb22a9325fc
binding binding4 management-ip 119.15.112.22 physical-port in1 vlan 119 network-id 1d475afc-d892-4dc7-af72-9bd88e565dde
midonet> vtep vtep0 binding binding4 show vlan
119
midonet> vtep vtep0 binding binding4 delete
midonet>

Fix MN-1824
Several issues here:

- So VtepBinding should be declared as a subclass of RelativeObjectRef instead of ObjectRef as it is now.
- This, however, doesn't solve the inherent issue here. Regardless of the class comments for ObjectRef, shouldn't the current context be always consulted first for reflection before looking in the top-level application context?
- We can override "fetch_one_for_type" in RelativeObjectRef, but that doesn't make sense and still affects other RelativeObjectRef subclasses.

We considered providing the lookup method with the top-level application, but that didn't quite seem right for the resource model of the Rest API. Port is, for whatever reason, a top-level entity in MidoNet, even though as you pointed out a port is nothing without a bridge or a router. So it's fine that the lookup method is defined at the top level. But VTEP binding isn't top-level entity. We can still define the lookup method at the top-level application, but we're not sure if that's really consistent with the overall REST API model.