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
"So VtepBinding should be declared as a subclass of RelativeObjectRef instead of ObjectRef as it is now."

IIRC correctly, RelativeObjecRef (badly documented) is meant of references of children of other objects. For example: this reference points to "a port within a router". They allow you to do this for instance: "router router0 port port0 set peer bridge0:port0"

"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?"

Conceptually you are totally right, that'd be much better. However, the midonetclient API isn't laid out like that. All resources (even rules) get top-level getter method at the root. And their parents only get a list_XXX() method. Example: get_rules() in chain.py and get_rule(id) in application.py. This is why all object reference work from the root and only the root.

An exception to this is port bindings. What happens here? They have no id and no top-level getter. Only a list_bindings() method in the Host class. There is no getter!. That's why the CLI has the "select an object from a list by filtering its attribute values" mechanism that we are discussing below. When you do something to a port binding object in the CLI, the CLI is fetching the list and selecting based on values, it's *not* using a getter.

What it looks like to me is that you are in no-mans-land between the "object with ID and root getter" model and the "port binding" model. And that's where the pain is coming from. If you embrace the "port binding model", with no id and field-value based selection. You lose this problem. If you embrace the top-level-getter model, you lose this problem too.

If you stay in the middle you are adding/modifying the established semantics. And there isn't anything inherently wrong with that, but it forces you to extend/modify the engine (like in this snippet) and to think more broadly about general syntax/model consistency so that it feels like it 'fits' with the rest of the model from a user's point of view.