Allow initialization of MeasurementKeys with empty strings

[dstrain115]

• An empty string is still a string and is used occasionally as a
  placeholder in user code. We should support creation of measurement
  keys with empty strings.

[dstrain115]

Question to cirq-maintainers. Is this sufficient to prevent problems with backward incompatibility or should we roll back instead?

[Strilanc]

name has annotated type str, not Optional[str]. How can it be None? Just from the code it looks like this should be an isinstance check, but I know you intend None to be some kind of placeholder instead.

[mpharrigan]

Can you add a reference to the PR that introduced the change so we have it on the record. GitHub will also show this PR to any future viewers of the previous one

[smitsanghavi]

The PR introducing this change was intentionally breaking since

1. There was inconsistency between cirq.measure(q) and cirq.MeasurementGate().on(q) for some qubit q. The former would assign the measurement key q while the latter would have an empty string.
2. We decided(1, 2) that dynamically remapping empty keys based on what qubits are operated on was not a desirable solution.

So, either we could keep this inconsistency, change cirq.measure to stop assigning the "default" key or disallow empty keys in MeasurementGate. We went with the last option since it seemed that empty keys are not really much useful in real world circuits and simulations. Since our Results are keyed by a measurement key string, it doesn't seem too radical to make the key argument sort-of required when constructing a MeasurementGate.

[dstrain115]

@smitsanghavi At the very least, we have to at least temporarily roll this change back, since a significant amount of internal code uses the empty string as a placeholder for "anonymous" measurements. If we want to re-break this, we need to migrate that code first.