In commit v3.7.0-rc1~158^2 (ExternalData: Tolerate files duplicated
across multiple targets, 2016-07-07) we added a test case for repeating
the same data file reference in three different targets in the same
directory in order to exercise its corresponding fix.  However, we
re-used the top-level `Data.dat` file which is already produced by
an unrelated test case.  `ninja` diagnoses the duplicate rule.

Update the test to use a dedicated data file name for the three-times
repeated case to avoid this conflict.  It still covers the original
purpose of the test.

Add support for projects to have `Data.txt.md5` *and* `Data.txt.sha512`
where the content links hold hashes for the same file.  Check all
`ExternalData_URL_TEMPLATES` entries in order for all available hashes.
The data acquisition is considered a failure if none of the available
URL resources has any of the given hashes.  This makes it possible to
have multiple data server resources where all servers do not support all
hashing algorithms.

If multiple ExternalData_Target_Add calls generate the same output file
then we need to avoid calling add_custom_command multiple times with
that output.  This was already done within a single target by setting a
variable in the local function scope.  This will not be visible in other
calls though so we need to use a directory property instead to prevent
adding a custom command multiple times for one output in a directory.

Normally it is not safe to have multiple custom commands that produce
the same output file across multiple independent targets, but since we
use atomic replacement of outputs the resulting races should not be a
problem.  For the convenience of projects, tolerate this instead of
diagnosing it.  In particular, we previously allowed up to two copies
of the custom command in one directory because CMake has a fallback
from MAIN_DEPENDENCY to an `<output>.rule` file.

While at it, add a note to the documentation that typically only one
external data target should be needed for a project.

Reported-by: David Manthey <david.manthey@kitware.com>

Add an ExternalData_NO_SYMLINKS to enable use of copies instead of
symlinks to populate the real data files behind a DATA{} reference.
This will be useful on UNIX-like systems when the underlying filesystem
does not actually support symbolic links.

Suggested-by: Matt McCormick <matt.mccormick@kitware.com>

Extend the ``DATA{Dir/,...}`` syntax with a new ``RECURSE:`` option
to enable recursive matching of associated files.  This will allow
an entire directory tree of data to be referenced at once.

Allow URL templates to contain a %(algo:<key>) placeholder that is
replaced by mapping the canonical hash algorithm name through a map
defined by the <key>.

Extend the Module.ExternalData test to cover the behavior.
Extend the RunCMake.ExternalData test to cover error cases.

Add support for a special URL template to map the fetch operation
to a project-specified .cmake script insead of using file(DOWNLOAD).

Extend the Module.ExternalData test to cover the behavior.
Extend the RunCMake.ExternalData test to cover error cases.