[wix-devs] Burn Variable breaking changes

[Sean Hall]

I'd like to design the following issues so I know which ones require a
breaking change:

https://github.com/wixtoolset/issues/issues/4763
https://github.com/wixtoolset/issues/issues/4863
https://github.com/wixtoolset/issues/issues/5319

4763 added the ability for Burn to set a variable as a literal string. I
think it's pretty straightforward to expose VariableSetLiteralString to the
BA. Doesn't seem to be a breaking change.

4863 is about wixstdba (through thmutil) allowing an editbox to be either a
literal string or a formatted string. If it's a literal string, then the
value should not be expanded when populating the editbox. If it's a
formatted string, then the value should be expanded when populating the
editbox. Should thmutil ask for a SetLiteralStringVariable callback and the
editbox is configured as literal/formatted in the theme? Or can a variable
be authored as a literal string (so thmutil and wixstdba won't be aware
that they're setting a literal string, the Burn engine will just handle
it)? Making thmutil format the variable when populating the editbox is a
breaking change, but adding the literal support doesn't seem to be breaking.

5319 is about the managed BootstrapperEngine implementation where it
exposes StringVariables, NumericVariables, and VersionVariables. The
complaint is that calling NumericVariables.Contains("StringVariableA")
returns true even though the variable is actually a string and not a
number. Do we remove the Contains method from all 3 and provide a single
Contains method so it doesn't imply that the variable is of the requested
type? Or does Burn provide a way to expose what the current type of a
variable is? Either way sounds like a breaking change.