WIP Revert preview string transformtion and allow users to use numeric format when converting string to object.

[mjkkirschner]

Purpose

#13861

I found that while this PR:#13744, initially seemed like a good idea, that it leads to lots of user confusion because it modifies the display values of strings all over the application, but does not actually address the bug it was implemented to fix since it does not actually modify the string data, but only its preview.

I believe the implicit transformation of the preview of user strings to be confusing. Strings are raw data, and we should not be modifying them without explicit user control, we should especially not be modifying them when the underlying string data is actually different - how is a user to know what is going on!?

Here is an example of the wackiness you can create with current master

It also will lead to strange behavior when mixing strings from different cultures, this is a perfectly reasonable thing to do, as strings have standard encodings exactly for this reason. ( see the linked issue)

Instead, this PR does the following:

• reverts the behavior in the linked PR.
• adds some new overloads for the string conversion methods that the String From Object and String From Array nodes call internally.
• modifies the builtin methods and string from nodes to accept a second optional parameter useNumberFormat - when true the node will convert the primitive or array to a string and use the user's number format preference to control the format of the generated string.
• adds two new nodes StringFromObject and StringFromArray 2? Still thinking of better names.
• Obsoletes the original nodes.
• During deserialization, if an old node is found (missing the new optional port) - then we add the port - this lets use migrate old graphs without introducing a new node or migration etc.

TODO:

• add tests
• cleanup method names
• add localized resources
• consider additional controls for using standard c# string formats - I think this is out of scope for this PR and bug fix and will need to be a followup task.
• assess with the teams if this should make it into 2.19 or is too risky
• if this is intended only for 3.0, then get rid of the obsolete methods if we can avoid breaking graphs, I think we can.

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated
• This PR contains no files larger than 50 MB

Release Notes

• add new port to String From nodes that allows control over format of generated string using preference setting.

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

[sm6srw]

Looks good to me...

[sm6srw]

But I missed that fact that you have failing tests....

[mjkkirschner]

okay, so I figured out that the test failures are because my workaround for not creating a new node or migration doesn't work for deserializing 1.0 graphs in xml format. I don't really want to mess with that at this point. I will try introducing a new set of nodes and obsoleting the old ones instead without removing them.