Allow merge conflicts to be resolved from the CMS UI

**Is your feature request related to a problem? Please describe.**

Merge conflicts are an inevitability, and cannot be resolved from within the CMS. As we advance into more complex functionality, the problem of merge conflicts will come to the forefront - for example, it should be possible for two edits of the same file to occur. Consider a single data file containing info about all authors. In the future we'll allow multiple files to move through the workflow as a single entity, so you could have two groups of files/changes, both of which add an author to the bottom of the authors file. Whichever changeset is published last will be unmergeable, and will require manual resolution.

This is also required to allow for scenarios where all edits don't take place in Netlify CMS.

**Describe the solution you'd like**

Provide a UI flow for resolving conflicts. Considerations:

- We can't subject editors to an actual rebase of multiple commits over the base commit, so we'll simply compare the base blob to the head blob in the UI and replace all commits in the PR with the resulting commit.
- There's a [nice lib](https://github.com/flitbit/diff) that can handle the actual diffing.
- We would show a single field at a time, with the widget displayed twice side by side - one with the base value (non-editable) and one with the head value (editable).
- An option should be provided to just go with one value or the other, as is.
- Individual widgets would determine how to display the base and head values. For simple widgets like `string`, you would probably just show the values with no further treatment. For more complicated or lengthier values, detailed diff data passed into the widget can be used to visualize the specific changes within the value.
- The editor should be notified when the target file in the base branch changes and the current changeset is unmergeable.
- It should be possible to resolve conflicts at any time once a conflict is known, but it shouldn't be required until publishing is attempted.

**Describe alternatives you've considered**

- Only allow one set of unpublished changes per file - this makes the case described above impossible to achieve, as data files for our purposes are like database tables, and you can't limit an entire table to only have one change in draft status.
- Bypass all of this by using collaborative editing so every file only ever has a single state. This is extremely non-trivial, and requires an external service to arbitrate between concurrent editors. Not an option until we have a turnkey solution for that, and even then, it shouldn't be required, so we'd still need the ability to resolve merge conflicts.