start a session as ssm-user with runAs option

[gurpalw]

#217

Issue #217, if available:
#217

Description of changes:
If RunAs is enabled, and the RunAs user is set to ssm-user, the session will fail to start.

This change fixes that by allowing the user/role creating the ssm session to use ssm-user, and creates the account for them in the same way as when RunAs is not enabled.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[laurentlgm]

RunAs default behavior is confusing and poorly documented. If you use different roles tagged with different users for the same instances (pretty normal scenario) then one of these roles cannot be tagged with "ssm-user" until you access the instance with an existing user and create the ssm-user. If you remove the RunAs config from the SSM setup then your tagged users cannot get in...and if you do that after launching the instance then you're out of luck.
e.g. I'm creating AL2/Ubuntu instances and roles via CDK and although my sudo-capable users can access the instances using ec2-user/ubutu default users after creation, my roles with ssm-user in RunAs cannot access the instance until I either manually create ssm-user or , as I've been doing, create ssm-user via user_data script.

[carterwilliamson]

Can this move forward? This behavior is universally described by users as bad. Having this would unblock a much needed ability to protect access to machines as @laurentlgm described.

If you look at the github issues related to this topic, AWS seems to be going through and just closing them which is odd considering this is a clear use case that should be supported.