Re-evaluate forked Redis / Redis HA charts

Summary

We forked Redis in the past for reasons as documented in our architectural decisions document. Since then, Bitnami has taken over stable/redis, and integrated HA.

Previous reasoning

Populate the password directly into the redis.conf instead of via Environment

This is addressed by usePassword and usePasswordFile

Make use of pre-existing Kubernetes secrets instead of creating new ones from properties.

This is now available via existingSecret property.

Benefits of using upstream

1. Remove redis and redis-ha forks
2. No undocumented behavior when redis & redis-ha charts are both enabled somehow
3. Reduced load on our team for maintenance
4. Now a StatefulSet, being more resilient

Downsides

1. Blocked due to need for major version change
2. breaking due to altered data / structure
3. Defaults cluster.enabled: true, cluster.slaveCount: 1 resulting in 2 pods vs 1 as current.

cc @jsalmeron @twk3 @joshlambert