Keep config and schema unchanged during a release (#5010)

Some of our documentation is auto-generated from the source code (the
defaults section in Config.md, and the keybinding cheat sheets), and so
is the JSON schema for the config file. We have a check running on CI
that verifies that when the source code changes (e.g. a new config
option is added), those files are properly regenerated, to make sure
they are always up to date with the latest version of the source code.

This causes a problem when people look at the documentation for a newly
added config option and wonder why it doesn't work in the lazygit
version they are using. Lots of issues were filed where people report
this as a bug, and we have to patiently explain to them that the
documentation describes a feature that hasn't been released yet. A
similar problem occurs when we rename a config option (as has recently
happened with the 'paging' config, which was renamed to 'pagers' in
#4953), in which case the user's editor (if it supports JSON validation
against the jsonschema store) starts to complain about the old config,
even though it still works, and the new one doesn't yet.

To solve this, keep the documentation and the JSON schema unchanged for
the lifetime of a release; make those continuous changes in a separate
copy of those folders, and only copy the files back to the real location
right before we make a release. To facilitate this, we add a script to
conveniently create a PR for copying the files back, and add a check to
the release workflow to abort with an error if this was forgotten.

Note that we only use this approach in order to solve the problem with
the auto-generated files; this has a consequence for making changes to
the other, non-auto-generated parts of the docs. For example, when
fixing a spelling error, rewording a paragraph to explain it better, or
adding an entirely new file, those changes will now have to be made in
docs-master, which means:
1. if we forget this and make the change in `docs` accidentally, it will
be reverted with the next release.
2. if we do remember to make the change in docs-master, it will take
until the next release for it to be visible to users.

We can mitigate 2. by making the identical change in both places, but I
think we should first wait and see how often it happens, and whether it
is actually a problem.

Author: stefanhaller

.github/workflows/release.yml

@@ -70,6 +70,15 @@ jobs:
             exit 1
           fi
 
+      - name: Check that docs and schema are up to date
+        run: |
+          if diff -r -q docs docs-master > /dev/null && diff -r -q schema schema-master > /dev/null; then
+            echo "Docs and schema are up to date."
+          else
+            echo "Docs or schema are out of date. Please run 'scripts/update_docs_for_release.sh' and make a PR."
+            exit 1
+          fi
+
       - name: Check for Blocking Issues/PRs
         if: ${{ !inputs.ignore_blocks }}
         id: check_blocks