Add support for Vault KV secrets engine v2

[philippgille]

This PR builds on top of #84 (thanks @mopemope!), but completely separates the handling of Vault KV secret engine v1 and v2 to ensure that no breaking changes are introduced for v1 users, for example when asking for the secret with key "data".

This PR also

• adds a test for the v2 backend, also adding a newer Vault version in CI (not the newest one, only the oldest one that leads to our Vault backend v1 implementation not working anymore)
• changes the tests to use "data" as key to make sure no handling of "data" in the implementation breaks that

ℹ️ In the future it could be nice to have both secret engines handled by one backend, but it might require a bit more work, similar to what the Vault CLI does here: https://github.com/hashicorp/vault/blob/28fc7714655b34d700150f8f81589013d6a07e55/command/kv_get.go#L94-L147

Background info:

• Secrets engine v1 API: https://www.vaultproject.io/api-docs/secret/kv/kv-v1#read-secret
• Secrets engine v2 API: https://www.vaultproject.io/api-docs/secret/kv/kv-v2#read-secret-version
• v0.10.0 release notes mentioning the "complete backend revamp" and introduction of versioned KV: https://github.com/hashicorp/vault/blob/00dfb97d67bd9eac5661b0ec62695b2c19e166cf/CHANGELOG.md#0100-april-10th-2018

[skateinmars]

🚀

[ckawasaki-isp]

Looks good to me.

[philippgille]

The CI jobs only failed because the Vault Docker container didn't start for some of the build jobs (Docker registry rate limit hit), but 1. not consistently for the PR and push builds (in one the Go 1.12 build worked but not the Go 1.13 one, the other way around in the other build), 2. both builds worked on Travis CI in another branch with the same changes recently and 3. the tests succeed locally. => Merging.