(feature) Add Amazon S3 backend

[mariotacke]

This PR adds Amazon S3 backend support to Nuts. Assets are proxied through Nuts and do not need to be public. Access to the assets is facilitated through Amazon access key and secret key which can be set through environment variables. This is a rudimentary implementation and serves as a base.

Added Environment Variables

• NUTS_BACKEND: Select backend to use. (github, s3)
• AWS_ACCESS_KEY_ID: Your AWS Access Key ID which can access the assets
• AWS_SECRET_ACCESS_KEY: Your AWS Secret Access Key
• AWS_BUCKET: The Amazon S3 bucket containing the assets (Ex: my-bucket)
• AWS_RELEASES_PREFIX: An optional path prefix to the releases. (Ex: my-app/releases)

[nickbeckenham]

Although I'm not a maintainer, I wonder if the configuration for backends should be contained per backend.
So for example, rather than opts.credentials.aws.* and opts.configuration.aws.*
perhaps it should be opts.backends.aws.* ?

Also to avoid clashes with other software on a system, perhaps the env items should all start with NUTS with a failover to a non-NUTS prefix. So for example instead of
accessKeyId: process.env.AWS_ACCESS_KEY_ID
it becomes:
accessKeyId: process.env.NUTS_AWS_ACCESS_KEY_ID || process.env.AWS_ACCESS_KEY_ID

That way users can have the aws access key defined once for all their apps if they want or if they have different permissions for different apps there is a NUTS specific aws access key that can be used?

[mariotacke]

I agree, the configuration should be compartmentalized per back-end. I implemented it this way to have less friction with the current structure. Overall, I agree with you however. I used the generic AWS env keys, because it worked for my use-case (I'm setting the same ENV for AWS for multiple processes). You could even specify an ENV key to use, or otherwise fall back to the default as it is.

[loprima-l]

Hi, I merged the project to a new repo to start maintain it, I would be glad if you can put your pull request here : https://github.com/loprima-l/nuts-2