Consider groups of translator options based on use case for ELM

[brynrhodes]

Currently, translatorOptionsMatch is built to include any change in CQL behavior and/or ELM output. Consider more fine-grained controls to support different use cases for ELM usage:

Master option:

EnableAnnotations
Language Features:

DisableListTraversal
DisableListDemotion
DisableListPromotion
EnableIntervalDemotion
EnableIntervalPromotion
DisableMethodInvocation
RequireFromKeyword
Annotated Helpers for Interpreters:

EnableResultTypes - function overloads
SignatureLevel - function overloads
Dependency Loader Control:

EnableCqlOnly - Doesn't load pre-compiled ELM (JSON or XML) dependencies
CompatibilityLevel - Compatibility level for the translator, valid values are 1.3, 1.4, and 1.5
Debbuging Information for Language Servers.

EnableLocators - Find source of errors
ErrorLevel - Error, Warnings, Info, etc.
EnableDetailedErrors -
EnableResultTypes - Code completion
I think the most difficult one is CompatibilityLevel, which is currently used in the dependency library loader but in a way that only loads libraries that declare exactly the same compatibility level value the loader is expecting as opposed to just using the option in the compiler to check if the library is compatible with that version (removing the need to compare the annotations themselves)

[mdnazmulkarim]

cqframework/clinical-reasoning#286