[wrap-guide] Make the automatic modification of editor.preferredLineLength configurable

[confused-Techie]

In short, the wrap-guide package will automatically sync the setting of editor.preferredLineLength whenever it's own settings are changed. Except it will only set the editor.preferredLineLength to that of the currently open syntax. Which can be confusing and downright unhelpful depending on your use case. Much more information is available on #697

But this PR takes the simpler approach to this, in case anybody has come to rely on this behavior, where we make this behavior configurable within wrap-guide introducing a new setting wrap-guide.modifyPreferredLineLength which by default is true (So that we don't change behavior on anyone) but does mean this function can be turned off to stop the unexpected behavior.

---

Resolves #697
Resolves #696

[mauricioszabo]

Do you think you can add a test case for this change?

[confused-Techie]

Do you think you can add a test case for this change?

Yeah lemme see what I can do here

[confused-Techie]

Alright, @mauricioszabo and done. We just gotta let tests run to ensure it's working as expected in CI

[DeeDeeG]

I sort of recall what this was about.

Code looks reasonable with a quick skim, and test cases are added.

This is admittedly a somewhat cursory review, but seems legit! Approving...

[DeeDeeG]

We do only have a negative test case "preference disables modifying the user's other preference if set".

Would be Excellent to have a positive test case "modifying other preferences is allowed and works, if the user specifies they want to allow that".

I dunno if it's a requirement to add such a test case, I leave that to the judgment of the PR author, but it seems like a good thing to me from my vantage and after my (admittedly brief) review.

[confused-Techie]

@DeeDeeG Thanks a ton for review!
I believe there are already tests for the positive case, but I can always double check. Since the positive case has been default behavior for quite some time.

So I think we are covered on that front.

Otherwise since I know we are in a slight rush, I'll go ahead and merge this then take a double check after the fact.
But thanks again!

[Daeraxa]

Oh damn I didn't realise this got merged, from the conversation it seemed like it was going to miss the 110 release. I didn't add it to the blurb, sorry about that.

[confused-Techie]

Oh damn I didn't realise this got merged, from the conversation it seemed like it was going to miss the 110 release. I didn't add it to the blurb, sorry about that.

No worries at all. Last we left it, it wasn't going to get merged. Only once we realized that did we last minute get it included, so not at all something you missed, just last minute stuff sneaking by

[Daeraxa]

One thing though, it looks like this made it to the top of the changelog but not into the individual "PR" section of 110?

[confused-Techie]

One thing though, it looks like this made it to the top of the changelog but not into the individual "PR" section of 110?

Yeah looks like you are right about that.

So that's a little messy, would we want to add it retroactively to the changelog?

[Daeraxa]

The main repo changelog is meant to be the source of truth so I think it is important to add it in there. I don't think it needs to be added into the current regular release changelog unless we do a 1.110.1 for a diffeerent issue.

[confused-Techie]

Yeah good call, I'll get that added