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
That's because I thought we wanted to reduce / remove direct dependency of the CLI code on the midonetclient code, where the former is open-sourced while the latter is not. It is my speculation that midonetclient.api.MidonetApi is the minimum interface API between the two, and therefore the rest of the interfacing between the two packages are to be done in the form of reflection. This patch introduced another dependency, midonetclient.resource_base.ResourceId, which may already be bad enough and may never make it. Since is_valid_ipv4_address is used only within the midonetclient modules, I declared that in midonetclient.util, while I kept the predicates for UUID and MAC in the CLI module.