Enhancement Suggestion / Bug Report

AWS recommends to use assume roles for cross-accounts management (which is the standard approach in a company). Rome can support profiles but the role_arn seems ignored and therefore, users get access denied.

Steps which explain the enhancement or reproduce the bug
For a matter of simplicity of repro steps, I give steps with admin rights while in real scenario, users would be granted only some roles and the roles would have less privileges too.
Note that this tutorial can be useful for people that are not used to this mechanism.

1. Create two AWS accounts (named A and B below)
2. On account A, create a user account "myuser" and gives him admin rights
3. On account B, create a S3 bucket for Rome (region=us-east-1)
4. On account B, create a role that can be assumed from account A and gives him admin rights
5. Login on account A with "myuser" and click on switch role to assume the new role on account B: validate you are able to browse/read/write from the console
6. Configure the CLI to have a profile which assume this role (profile with a line role_arn='<full_arn>').
7. export AWS_PROFILE='<yourprofilename', export AWS_REGION='us-east-1'. Validate you can list the buckets with "aws s3 ls". You should see the buckets from account B and use it properly
8. Use Rome with this profile. You'll get access denied. (which makes me believe Rome is not ignoring the role_arn while the AWS Cli is using it)

Current behavior
Access denied -> Rome doesn't seem to assume role.

The workaround is to create a shared service account on "account B" and to provide the access key to our users (we don't want to create user accounts on "account B"). This workaround is a bad practice.

Suggested behavior
Role should be assumed.

Why would the enhancement be useful to most users
This is how most organizations are/will be using AWS in production.

Rome version:
0.19.0.55 - Romam uno die non fuisse conditam.

OS and version:
MACOS, Mojave
OS is probably not important here.