#16388 introduced a bug where, with `--junit-format=global`, the junit
file would indicate an error (with no message) even if everything
passed. That was because `_generate_junit_contents` would check if
`messages_by_file` was empty or not to determine if there were failures,
but with `--junit-format=global` we'd pass in a dictionary of the form
`{None: all_messages}`; `all_messages` would be empty, but the resulting
dictionary wouldn't be.

The fix is to pass in an empty dictionary if there are no messages.

I've tested manually with `--junit-format=global` and
`--junit-format=per_file` in the successful case to make sure the files
are written correctly now.

#16388 changed the definition of
`write_junit_xml` but missed a call site in dmypy. This fixes it.

#16388 introduced a bug where invalid xml could be produced by
`write_junit_xml`, as special characters were no longer being escaped.

The fix is to revert the removal of `from xml.sax.saxutils import
escape` and `escape("\n".join(messages))` in the `write_junit_xml`
function.

I've added a small test case which checks that the `<`, `>`, `&` are
escaped correctly in the xml.

the inclusion into imports group seems to have been a mistake in python#16388 although one could perhaps argue it is tangentially related to imports in some way. But it does not influence import discovery, unlike the other options.

Elaborate on the information given in --help and command_line.rst for
junit, to make it more correct and comprehensive.

I manually examined the generated results and found them satisfactory.

Note that this also puts --junit-format into misc group not import
group; the inclusion into imports group seems to have been a mistake in
#16388 although one could perhaps argue it is tangentially related to
imports in some way. But it does not influence import discovery, unlike
the other options. Putting it into import group also makes it display in
a completely different place, which is not as helpful as right next to
its related option.