Add support for gradual code deployment for lambda function

SAM supports a nice feature to [safely deploy](https://github.com/awslabs/serverless-application-model/blob/master/docs/safe_lambda_deployments.rst) new version of a lambda function including traffic shifting and automatic rollback functionality.

Adding support for this feature, including all the pre/post hook lambda functions, alerts, deployment variants, in the outputted SAM definition file, would be a good step forward to make it more useful in production environment in my opinion.

I already added this functionalily in a very simple variant in one of my side project and it would be a pleasure to support here to add this to chalice!

**Proposal**

I would suggest to add a new (stage dependent) config parameter in `.chalice/config.json`:

```JSON
{
"stages": {
"staging": {
"deployment_preference": {
"type": "Linear10PercentEvery1Minute",
"auto_publish_alias": "live"
}
}
}
}
```

For instance, check [here](https://github.com/awslabs/serverless-application-model/blob/master/docs/safe_lambda_deployments.rst#traffic-shifting-using-codedeploy) for an example SAM file including pre/post hooks and alarms that need to be generated out of the config above. Since the alarms could be static at first as in the example (error rate of new and old lambda function) but could be more complex in future.

Thus, the example above should extend the SAM lambda definition with:

```
"Type": "AWS::Serverless::Function",
"Properties": {
...
"AutoPublishAlias": "live",
"DeploymentPreference": {
"Type": "Linear10PercentEvery1Minute"
}
}
```

It would be nice to also have the possibility of a lambda implementation and definion within chalice for the hooks. But I don't know how complex this is.

I already started a [possible implementation](https://github.com/gallmerci/chalice) of this (without alarms and hooks at the moment).

Start with the proposed stage-dependent settings in .chalice/config.json and the generated SAM definition, then read the linked SAM safe_lambda_deployments.rst example. Compare the requested deployment preference, alias, alarms, and hook behavior with the existing output. Done means the configuration generates the required SAM resources, including the requested deployment settings and any supported hooks or alarms.

Written by the indexing model from the issue text.