feat: Redesign option list items so keys are GUIDs rather than strings

[rmunn]

Is your feature request related to a problem? Please describe.
After thinking about the issues with option lists and Send/Receive (#976, #977, #1295, #1552), I've come to the conclusion that our option lists in Language Forge need an architecture change. We currently have name and abbreviation as strings, and also the key as a string as well (and it's usually something that matches the abbreviation, like "v" for a verb). Instead of a string, the key needs to be a GUID.

This would greatly simplify the Send/Receive code that deals with option lists, which are keyed by GUID in FieldWorks. Right now the code is having to take the key "v" in Language Forge, treat it as if it were an abbreviation, and guess which writing system to look up that abbreviation for in the FieldWorks data to find the GUID for that option list item. And if the FieldWorks user changed the default grammatical lists because his language uses vb as the abbreviation for "verb", or if the abbreviation for verb is ก instead of v... then that lookup fails, and the Send/Receive code falls back on *** (plus an integer value to ensure uniqueness) as the final "I can't figure it out, so just use something unique" fallback. But that value then leaks back into the user interface. and people see *** or ***1 or ***2 in their dropdown lists, which is very very poor UX.

Switching the option list keys to be GUIDs instead of strings will, I believe, allow us to finally put that *** bug to rest.

[megahirt]

yes, I agree we should go this direction. Thanks for the issue and background info!