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
Things are not exactly how this comment describes. Quoting the ObjectRef class definition:

class ObjectRef(ValueType):
    """A reference to an object found in the root lookup context (see class
       Midonet)"""


In other words: object references are meant to point to objects that are reachable form the root app context. The reason behind this is that this follows our REST API model and the python client library where, for instance, you fetch single ports from the top level even though a port is nothing without a bridge or router to contain it.