fix: Pin `lsprotocol` depdency

[tombh]

This is on recommendation from the main lsprotocol developer. There is a much larger discussion around pinning in general, see: https://github.com/openlawlibrary/pygls/issues/331

Code review checklist (for code reviewer to complete)

• [ ] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR)
• [ ] Title summarizes what is changing
• [ ] Commit messages are meaningful (see this for details)
• [ ] Tests have been included and/or updated, as appropriate
• [ ] Docstrings have been included and/or updated, as appropriate
• [ ] Standalone docs have been updated accordingly
• [ ] CONTRIBUTORS.md was updated, as appropriate
• [ ] Changelog has been updated, as needed (see CHANGELOG.md)

[tombh]

We've actually got lsprotocol==2023.0.0a2 in master now, so I'll close this branch.

But one little open question I have is, is it worth testing out lsprotocol==2023.0.0a2 in the wild a little bit before making a new release of Pygls? #331 shows that there was a lot to take into consideration in introducing pinning, so maybe we should just make sure there aren't any unintended consequences first?

[karthiknadig]

I think it is safe to pin 2023.0.0a2. I will be releasing 2023.0.0a3 next week and it will need some time in the wild to settle. My plan is to get this to stable this quarter. Then we can have pre-releases without impact to main pygls

[tombh]

Thanks for the heads up. We'll make a release of that 2023.0.0a2 pin then, so you'll have the freedom to let 2023.0.0a3 into the wild without putting Pygls users into a tight spot.