Improved concurrency handling in `pull`

[ambsw-technology]

I've been digging through the implementation and it looks like the force flag in pull only supports two modes:

• Keep all local value and add any new values from SSM (don't force)
• Overwrite all local values with all remote values, implicitly preserving added values (force)

It would be nice to be able to provide more granular concurrency options. For example, consider the following three cases:

1. Key1 changed locally but not on SSM
2. Key1 changed locally and was changed in SSM
3. Key1 only changed on SSM

In git, the pull behavior is more like:

1. Preserves this value
2. Identifies the conflict and throws an exception (unless you prefer-local or prefer-remote)
3. Update this value

It'd be nice to support something similar.

[ambsw-technology]

If it isn't obvious, this request requires a local file that stores the remote values from the last time pull or init was run. I'd probably create a file like <filename>.orig right next to <filename>.yml.

[ambsw-technology]

As I dig deeper, I think the following case will result in unwanted behavior in the current implementation:

• init with a remote like {'a': {'b': {'c': 'd', 'x': 'y'}}}
• delete the remote key /a/b/x (on SSM)
• pull (with or without force)
• apply

In both cases, the pull will treat the local a/b/x key as "added". The key will be retained and restored to SSM when apply is run. Most users will probably want the tool to recognize the remote delete and update the local file accordingly.