Use container names to disambiguate backend stores

[timuralp]

s3proxy disambiguates backend stores by different credentials, which means that from the application side typically a new client needs to be created to connect to the different backends. To reduce friction, it would be great to be able to configure s3proxy with multiple backends with the same credentials and specify the buckets associated with them.

The specific use case is Azure, where multiple storage accounts are common, but being able to hide that complexity from the application would simplify access.

[gaul]

How to do these mappings since the existing properties file is too simple? #365 suggests putting them in a SQL database but maybe a JSON file or similar is more appropriate? One advantage of the properties is that its simplicity allows easy configuration via environment variables for Docker containers.

Related to #364. cc @berlinsaint

[timuralp]

I propose to still use the properties file and add a new configuration option, e.g. s3proxy.bucket-locator.buckets.<N>=<bucket name>. When s3proxy compiles the properties, it can add mapping entries (<identity>, <bucket name>) -> blobstore, as opposed to using only the identity as the key.

I recognize that the properties file is limiting, however, it is simple and if we can make this work without introducing a whole new configuration storage mechanism, I think that would be preferred.

[whybeyoung]

#372