Update Save annotation behavior

[ggeisler]

Related to #4.

@mejackreed I know you haven't finished all the details in issue #4, but relevant to our discussion about the transcription use case brought up by @damooo in https://github.com/ProjectMirador/mirador-annotations/issues/10#issuecomment-631354024:

Rather than add a new "Save and continue" button or introduce a new mode can we:

• [x] Don't close the annotation creation window on Save. The user who is finished with annotation creation can use the close button to get rid of the annotation creation window.

• [x] Retain the current selection of the various Add/Edit Target and Style tools in the panel (e.g., shape, target color) after save. Only when the Add/Edit Annotation window is closed do all options in the panel revert to their defaults.

• [ ] Always retain the current selection of the Motivation menu choice (when it is added).

• [ ] The options that should be cleared on Save are Tags (when we add tag creation) and the Content options (bold, italic, text area should all revert to defaults on Save).

• [ ] If necessary, scrolls the Annotation sidebar as necessary to ensure the saved annotation is visible. The annotation should be highlighted as if the user had selected that annotation; selected annotation gray background and selected annotation yellow region target highlighting:

This seems like the best combination of options for efficiency of most annotation use cases, and doesn't require any new buttons. The user who is making a single annotation needs to make one more click to close the Add/Edit annotation window, but for any use case involving multiple annotations, including the transcription use case, this approach would save multiple clicks and often be more efficient.

[cbeer]

@ggeisler : Should the cancel button in the annotation creation companion window still close that companion window, or just reset the state like saving does?

[ggeisler]

@cbeer I think Cancel should still close the anno editing panel. I could see a case either way, but this way we can be consistent about what action the Cancel button performs without having a situation where the Cancel button feels like it is inoperable (when you initially open it but haven't done anything in it yet).

And it seems like the worse case with that approach is the user is making a series of annotations and just wants to reset what they've done in the current edit -- we'd force that user to re-open the annotation edit panel (and possibly reposition the canvas area in view), but otherwise no harm is done.