Handle clients sending "null" instead of a missing field (#543)

* Accept null in place of a missing value

We sometimes see reports where HLS is not working because the client
sends us slightly wrong JSON. We should follow the principle of
robustness and try to accept this where we can - following the spec
precisely is hard!

The specific case we hadle here is accepting null to mean "missing"
when null is not a valid value for the type. Currently we will treat
it as a _present_ value and then fail to interpret null as a value of
the type.

* Mark lsp-types generated code as generated for github

* typo

* Fix a few more

* Refactor tests a little

* Changelog

* Improve comment

Author: michaelpj

.gitattributes

@@ -1 +1 @@
-lsp-types/generated linguist-generated=true
+lsp-types/generated/** linguist-generated=true

lsp-types/.gitattributes

@@ -0,0 +1 @@
+lsp-types/generated/** linguist-generated=true

lsp-types/ChangeLog.md

@@ -3,6 +3,7 @@
 ## Unreleased
 
 - Require aeson 2
+- Accept `null` in place of a missing field, a common mistake in spec compliance.
 
 ## 2.1.0.0 -- 2023-11-13