Fix null encoding in new document in move type action

[Rekkonnect]

Closes #72984

Summary

We default to receiving the encoding set in the new node we are requested to create the new document with in DocumentState.

A new test was added to test how hot reload reacts by applying the code fix that contained the null encoding bug, and applying actual code changes after performing the move type. It seems that the bug was not being triggered if the code fix had no changes to apply, i.e. the code remained the exact same, and all that changed was the location of the moved type.

[CyrusNajmabadi]

seems reasonable. @tmat @jasonmalinowski any concerns?

[CyrusNajmabadi]

@tmat ccan you ptal?

[Rekkonnect]

@tmat could you please review this?

[Rekkonnect]

@tmat another reminder to review this

[Rekkonnect]

MSBuildWorkspacePreservesEncoding fails at Assert.NotNull(doc3text.Encoding); because of the last change where we always override the encoding of the syntax tree. This behavior must also be reflected in the test, so I'll modify that. We can also preserve the behavior of retaining the encoding if we already had an encoding and the new syntax tree has a null one.

[Rekkonnect]

@tmat ptal at the changed tests and review

[Rekkonnect]

@tmat ready for review

[Rekkonnect]

@tmat ready for review

[CyrusNajmabadi]

Set to auto-merge. If we don't want this, please speak up @tmat

[CyrusNajmabadi]

@jasonmalinowski ptal.

[CyrusNajmabadi]

@jasonmalinowski I don't have context on the previous logic. Should it ask be removed (like the current pr does it), it should we just fall back to getting the encoding from the tree if the other checks fail?

[Rekkonnect]

Note the previous comment from tmat: #74623 (comment)

[CyrusNajmabadi]

Ok. Seems reasonable. Merging in. If you have any concerns @jason let us know