Bug/319 localization double parse

[TimPurdum]

Closes #319

• Passes navigator.language with graphic attributes in dotNetBuilder.buildDotNetGraphic
• Uses the passed culture string if available to parse numbers and datetimes. Falls back to CurrentCulture.
• Added new unit tests to validate parsing
• Added support in TestRunnerBase.razor for synchronous tests

There is some question in my mind still if this is the "right" or "best" approach. The issue IMO stems from the following:

• Data sources, such as AGOL, can store feature data with a culture
• Client devices can have a different culture
• GeoBlazor servers could in theory have yet another culture

How these 3 pieces fit together, and how to know that we aren't breaking data in any one scenario (data from AGOL in culture A, data from GeoBlazor in culture B, etc.).

For example, if we pass data to ArcGIS JS layers in culture A from GeoBlazor, but the client is in culture B, when it returns to GB, it will have culture B tied to the data. Some of this stems from the fact that Blazor is both a server and client technology, often in the same application.

[TimPurdum]

Questions above aside, these changes will make GeoBlazor work inline with the ArcGIS JS SDK, along with a few other options that you could use to manipulate the AttributesDictionary server-side. I think that is a step in the right direction, it fixes the issue raised by an end user in Europe, and it should be merged.

[AndersenBell]

Would it make sense to make this a property on the class rather then another entry in the dictionary? It could help separate data vs framework, unless these attributes are not directly realted to the data.

[TimPurdum]

The problem is the serialization of the attributes, where we have to switch them to an array of objects with key, value, and valueType. I could rewrite all of that to be an object with an array, but this seemed simpler. Rewriting would mean rewriting both JSON and Protobuf serialization methods in both C# and TypeScript. 😩

[TimPurdum]

After discussing with @AndersenBell, we came up with a better plan. In my changes, we now query once for the browser language in JsModuleManager when the js modules are loaded. This is then referenced in AttributesDictionary to deserialize, and we no longer need to add the culture to each attribute dictionary.

[AndersenBell]

looks good