devguide: commit that changes behavior needs docs

If a commit introduces code that changes Suricata behavior, we
understand that the documentation changes should go in the same commit.
Among other things, this reduces the chances of said changes being lost
if there are backports or many work versions before approval.

doc/userguide/devguide/contributing/code-submission-process.rst

@@ -11,7 +11,8 @@ Commits
 #. Commits need to have proper messages, explaining anything that is non-trivial
 #. Commits should not, at the same time, change, rename and/or move code. Use separate commits
      for each of this, e.g, a commit to rename files, then a commit to change the code.
-#. Documentation updates should be in their own commit (not mixed with code commits)
+#. If your code changes or adds new behavior, update the documentation in the same commit.
+     Otherwise, documentation updates should be in their own commit (not mixed with code commits).
 #. Commit messages need to be properly formatted (check the example further
      below in this section):
       * Meaningful and short (50 chars max) subject line followed by an empty line