ML2 Type drivers refactor to allow extensiblity

Scope:
Problem
- Currently the ML2 segmentation is managed in multiple places within the architecture
- The plugin invokes the type manager with tenant/provider segment calls
- The manager in turn invokes the type driver to reserve an available/specified segment for the network
- The segment_id if reserved is returned all the way to the plugin which then stores it inside a DB.
- The type driver itself also has tables of it’s own where it stores segment details.

Proposal
- Move all segmentation management to the type driver(s), ML2 plugin and the type manager should only be making calls to the type driver(s) to get segmentation ID’s when required.
- Send real API calls, create_network and delete_network to the type driver(s).
- Type manager collates response from all type drivers loaded and responds with all replies keyed by type driver.

Use Cases:
Custom type drivers for externally managed overlay networks. Detalied use case in attached google doc spec.

Data Model Changes:
Changes to the ml2_network_segments model to store types instead of information returned by types

Configuration variables: n/a

API's: n/a

Plugin Interface:
Type driver interface with the type manager will change

Required Plugin support: n/a