Add auth option for redis

[D-Raiser]

Some instances of Redis (Microsoft Azure Redis Cache for example) require authentication before allowing any other commands to be executed.

[eli-darkly]

I'm not sure this is the right place for this.

AUTH needs to be the first command that we send - but is that per connection, or per connection pool? If it's per connection then we would need to do it every time we called store.getConn, i.e. for every kind of operation. But then we'd have no way of knowing if this is a new connection or a reused one.

I think possibly the way we're supposed to do this is by specifying the DialPassword option when we call redis.DialURL().

[D-Raiser]

@eli-darkly You're right, this should've been per Connection.

I updated the commit to use the redis.DialPassword option in redis.DialURL().

[eli-darkly]

I had two more thoughts about this, a bit late:

1. It should already be possible to specify a password in the Redis URL. I'm still fine with supporting a separate password option, but just wanted to mention that.
2. This isn't the only advanced Redis option that people might want to configure: for instance, there's the TLS option. Rather than surfacing all of these as separate options in our own API, I think it might be better to have an option like this:

// DialOption creates an option for NewRedisFeatureStoreWithDefaults to specify any of the
// advanced Redis connection options supported by Redigo, such as DialPassword.
//
//     import (
//         redigo "github.com/garyburd/redigo/redis"
//         "gopkg.in/launchdarkly/go-server-sdk.v4/redis"
//     )
//     store, err := redis.NewRedisFeatureStoreWithDefaults(redis.DialOption(redigo.DialPassword("verysecure123")))

That would mean we are surfacing Redigo API details in our own API, but that is already the approach we use in our other SDKs where we provide direct access to advanced configuration options of the underlying implementation of Redis or DynamoDB or the HTTP client or whatever—and if we ever release a Redis integration that does not use Redigo, it will be in a new major version (and possibly will be broken out into a separate project, rather than being a subpackage of the SDK). So I think I would rather add that general feature now, rather than trying to anticipate all the other options people might want to use.

[eli-darkly]

By the way, I've retargeted this PR to the contrib branch because we are trying out a new workflow for accepting external PRs. Since in Go, merging anything onto the default branch is equivalent to immediately releasing it, we're going to start accumulating contributions on a separate branch until we're ready to release.

[eli-darkly]

And since we're doing that, I'm fine with merging this now, and then we can consider making the additional changes I suggested.