devguide: doc from behavior changes need ticket ref

If a commit introduces code that changes Suricata behavior, the related
documentation changes should go in a separate commit, but refer to the
same ticket number.
This reduces the chances of said changes being lost if there are backports
while still keeping the backporting process a bit less bulky, for each
commit.

Related to
Task OISF#6568

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

@@ -11,7 +11,7 @@ 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 add the documentation updates in their own commit, but make sure to add the same ticket number to both commit messages.
 #. 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