Add georep fields to SC

[JohnStrunk]

Describe the feature you'd like to have.
The StorageClass design proposed in #30 lacks a way of specifying that the volume type should be georeplicated. Decide what fields should be configurable and how they should be exposed.

What is the value to the end user? (why is it a priority?)
Admins would like to be able to replicate Gluster-backed PVs to other Gluster clusters. The target cluster could be GCS converged, GCS independent, or standalone Gluster.

How will we know we have a good solution? (acceptance criteria)

• The fields exposed in the SC aren't redundant w/ other configuration
• The georep configuration for the volume can be fully expressed in the SC (nothing needs to be done to the PVC/PV or actual volume once created)
• Fields in the SC should assume that a cluster-level configuration is handled elsewhere

Additional context
The georep relationship (source cluster to target cluster) is at the cluster-level, so it should not be exposed or configured here. Instead, we should only refer to the peering relationship at the level of the SC:

• At the cluster level, there would be configuration: ThisCluster can replicate to ThatCluster (at addr X on port Y)
• The SC should just refer to "ThatCluster", ensuring that address and credential changes can be handled exactly once for the whole cluster.
• The cluster-level configuration is out of scope for this item.

Depends on #30