Always send correct end column when formatting

[Xanewok]

Closes #1421.

Previously we sent u64::max_value() in hope that it'll be supported by editors and to signify a 'line-wide' edit but now we try to always do the right thing and send an accurate diff.

[norru]

Ace, is this going to make it for tonight's nightly?

[Xanewok]

I don't think we'll make it - nightlies are deployed around UTC and the fix probably doesn't warrant bumping the submodules in Rust tree with increased priority. Having said that, I hope it'll make it in tomorrow's nightly; I'll prepare an update PR.

[Xanewok]

@norru by the way, does the formatting fail with the "character":<u64::max_value()> or does it just look really strange in the logs? Wasn't sure what's the case, I'd like to verify before sending the Rust PR.

[norru]

No formatting happens.

LSP4E rejects the entire response, as it contains an invalid range, and does nothing.

[norru]

I hereby summon @mickaelistria

[Xanewok]

LSP4E rejects the entire response as it contains an invalid range and does nothing.

Alrighty then, makes sense.

[mickaelistria]

The spec doesn't allow erroneous position. Eclipse LSP4E client fails (an exception happens because of invalid value) and the response triggers no edit on client side; but maybe some other clients may be more tolerant and could deal with it.
But in any case, the spec says that positions have to be accurate, so sending erroneous position is not supposed to be supported in the general case.