fix: Update built-in map-based ExperimentOverrideStore implementation to be concurrently usable

[mjc1283]

The built-in default implementation of ExperimentOverrideStore should be production ready, so it should be safe to use concurrently.

In this PR:

• The default implementation is renamed to MapExperimentOverridesStore
• A sync.RWLock is added to MapExperimentOverridesStore
• A SetVariation method is added for setting an override, which uses the mutex
• The GetVariation method is updated to use the mutex
• A new test is added that calls GetVariation and SetVariation concurrently from several goroutines

[thomaszurkan-optimizely]

https://godoc.org/golang.org/x/sync/syncmap why not use sync map instead?

[mjc1283]

@thomaszurkan-optimizely Based on reading this: https://golang.org/pkg/sync/#Map I gather that sync.Map, gives you better performance for certain use cases, and you don't have to implement locking yourself, but you give up type safety. Implementing locking is easy, and I don't know that we will always match one of those use cases, so it didn't seem worth giving up type safety. Let me know if you agree.

Also, aside from all that, can we even use it if we want our SDK to be usable in version <1.9?

[mikeproeng37]

Lgtm, just have a suggestion in the test

[mikeproeng37]

Can you also assert that the decision variation key matches what you expected?