Modular GlusterFS share layouts

Currently we have multiple drivers that integrate GlusterFS as a Manila storage backend (glusterfs and glustefs-native), and we have multiple share layouts that determine how GlusterFS is integrated into Manila.

Currently "share layout" is an informal term that refers to the model of choosing entities of the backing GlusterFS cluster(s) to back a given share. There are also two of these: with *volume mapped share layout* we take a whole GlusterFS volume to back a share; with *directory mapped share layout* we take top level directories of GlusterFS volume(s) to back a share.

Currently share layouts are bound to drivers:
- glusterfs driver is implemented with directory mapped share layout;
- glusterfs-native driver is implemented with volume mapped share layout.

Agenda:

- Share layouts should be abstracted, moulded into progammatically defined constructs (classes).
- Implict share layout implementations should be removed from driver scope.
- Respective configuration parameters should be added through which the storage admin can specify her choice of share layout.
- GlusterFS drivers should specify the list of share layouts they can work with; in case of an incompaible GlusterFS driver / share layout pairing the manila share service should throw an error with a message that clearly identifies the issue.