Migrate should respect locally configured credentials

**Actual Behaviour**

Regardless of the user's local environment configuration, all database migrations are run with mock access/secret key ids. This is both poorly documented and inconsistent with expecations; it also results in failed interactions with tables as noted in #183

**Expected Behaviour**

The existing behaviour is fine as a _fallback_; however, if `AWS_ACCESS_KEY_ID` and/or `AWS_SECRET_ACCESS_KEY` are set on the environment (as is common in most AWS-based infrastructures), those should be used instead.

**Steps to reproduce it**

1. Configure your local environment with either (or both) `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY`
2. Run `sls dynamodb migrate` to migrate tables configured in your `serverless.yml`
3. Verify a failure to connect by either:
3a. Using the `awscli`: `aws dynamodb list-tables --endpoint-url http://localhost:8000`
3b: Using the `AWS.DynamoDB` or `AWS.DynamoDB.DocumentClient` SDKs

You'll notice that both `3a` and `3b` above result in the tables created by migration not being found.

**Screenshots of the issue**

`serverless-dynamodb-local` can find the tables that it created earlier:


...however, `awscli` cannot not:


**Would you like to work on the issue?**

https://github.com/99xt/serverless-dynamodb-local/pull/204

Start at the `sls dynamodb migrate` command entry point and trace how credentials are selected for migrations. Verify the behavior with `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` set or unset, using the `serverless.yml` tables and the AWS CLI or SDK checks described; done means configured credentials are honored while mock credentials remain the fallback.

Written by the indexing model from the issue text.