Spike: Changing LMS GUID breaks existing annotations

This isn't so much a bug, but a statement of problem that sometimes occurs, which me may be able to find a better method of coping with.

Hypothesis LMS app uses the LTI parameter `tool_consumer_instance_guid` to uniquely identify the LMS instance. Occasionally an LMS instance will change the value of this parameter internally, breaking that's school's existing Hypothesis assignments and rendering all previous annotations made under the old GUID no longer visible.

There are a few circumstances where I've seen this occur:

- Sometimes an LMS has a blank `tool_consumer_instance_guid`; IMS considers this parameter "recommended" and not every LMS instance has this parameter populated. If Hypothesis finds a blank `tool_consumer_instance_guid`, it will define its own unique GUID to use for that LMS instance. If later the LMS populates `tool_consumer_instance_guid` (perhaps as part of a system upgrade), Hypothesis will begin using the actual value in `tool_consumer_instance_guid` and no longer identify annotations made under the previous GUID as connected to that LMS instance.
- A school will upgrade their LMS and the existing value of `tool_consumer_instance_guid` is replaced with a new value.

There may be other scenarios where the `tool_consumer_instance_guid` will change.

Ideally, Hypothesis would be able to weather a change of `tool_consumer_instance_guid` without losing that LMS's connection to previous annotations.

No files, tests, or entry points are identified. Start by locating the code that consumes the LTI tool_consumer_instance_guid and associates annotations with an LMS instance. Document the cases where the value is blank or changes, then define and validate a way to preserve access to existing annotations.

Written by the indexing model from the issue text.