There are three rules in helpcontent2/CustomTarget_html.mk that process (with
XSLT) all or some of the .xhp files in the helpcontent2/source/text/ tree (for
en-US; or their translations in the
workdir/HelpTranslatePartTarget/*/helpcontent2/source/text/ trees for other
languages).  Lists of all those .xhp files are defined in
helpcontent2/AllLangHelp_*.mk (with gb_AllLangHelp_add_helpfiles), but the code
in helpcontent2/CustomTarget_html.mk used `find` to assemble the relevant lists.

That has two issues (at least for the en-US case operating on the untranslated
helpcontent2/source/text/ files):  For one, if the content of those .xhp files
changes, the relevant XSLT processing is not re-run.  For another, if .xhp files
are added to or removed from the lists in helpcontent2/AllLangHelp_*.mk, the
relevant XSLT processeing is not re-run, either.

For the processing of translated .xhp files, there were already dependencies on
those translated files in place.  I assume (but have not really proved it) that
those dependencies are already sufficient to cover both of the above issues.
That only leaves the en-US case, operating on the untranslated files.

The lists of .xhp files as defined in helpcontent2/AllLangHelp_*.mk (with "*"
ranging over the various "modules": sbasic, scalc, schart, etc.) are now made
available in gb_AllLangHelp_*_HELPFILES variables.  The contents of those
variables is used instead of `find` to pass the relevant .xhp files to the XSLT
processings.  (Needing some RESPONSEFILE and `xargs -n 1` boilerplate to feed
individual files to the XSL processing without overflowing maximum command line
lengths.  Also, on Windows, var2file apparently writes CRLF line ends but the CR
parts need to be filtered out again, and xargs problems must be worked around
similar to df9edbcd "Work around 'xargs:
environment is too large for exec' errors on Windows".)

However, those variables apparently cannot be used to specify dependencies for
the three XSLT-processing rules.  Presumably, the variables do not necessarily
have their values assigned yet by the time the rules' dependencies are
constructed (depending on the order in which .mk files are read?).  So "dummy"
gb_AllLangHelp_get_helpfiles_target targets are introduced, which depend on all
the relevant .xhp files (and which get constructed during
gb_AllLangHelp_add_helpfiles, just like the gb_AllLangHelp_*_HELPFILES
variables), and which the XSLT-processing rules in turn depend on.  That makes
sure that the XSLT-processing rules are re-run when the content of .xhp files
changes or when new .xhp files are added.

However, the above still fails to re-run the XSLT-processing rules when .xhp
files are removed.

This is the core part of a commit spanning core and helpcontent2.

Change-Id: I0cb5f83097db17fbd7ae8b528418b0ec24bee602
Reviewed-on: https://gerrit.libreoffice.org/55363Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>