The new module system is target-based rather than variable based. All
information is passed between targets using target properties and
leveraging CMake where possible such as for things like include
directories and linking libraries.

Where CMake doesn't handle things automatically, we store properties
ourselves. This includes whether a module needs autoinit logic (and a
function to handle adding the autoinit logic to a set of targets), which
headers to wrap in various languages, etc.

We no longer provide a copy of the module with VTK, so link to
CMake's own online documentation of the module instead.

Change `ExternalData_LINK_CONTENT` from `MD5` to `SHA512` so that new
content links will be generated using the latter hash algorithm.
Update workflow documentation accordingly.

The dashboard buildbot links can only be reached from the kitware network.
When developers from the outside click the link, no buildbot list is
displayed.

This patch set uses the links available to people outside the kitware
network.

For reference, see https://www.vtk.org/pipermail/vtk-developers/2017-October/035502.html

Some VTK source code still had tabs (even some of the .py files!).
Also, several comments used utf-8 quotes, which are hard to tell
from regular quotes by eye and can lead to confusing mistakes.

Clarify that each branch update requires
a new test command and describe what buildbot
does if a new test command is issued before
a test for a previous update begins.

Adding guidelines for commit logs. This is needed to ensure some
uniformity in commit logs for the project.

We need more information from developers for new merge requests. This
adds guidelines that we can point them to, if needed.

Added instructions for verifying that pushed data has been uploaded
successfully after 'git gitlab-push'.

Code extracted from:

    https://gitlab.kitware.com/third-party/proj.git

at commit 41bdf05361007f8c5186f3df9944d86bb273ed13 (for/vtk).

Both rebase and cherry-pick are the normal ways.

These branches are not tied to our master branch in our workflow. Direct
merges to the old release branches are valid.

Also made explicit the required order of sections in a comment.

List the allowed leading and trailing lines that have special meanings.

Our 'git-gitlab-push' script requires Git 1.7.2 or greater to use the
'git -c <name>=<value> ...' configuration option.  Since 1.7.2 came out
in 2010 it is reasonable to expect developers to have it in 2015.

Also clarify how the main repository and user fork will be referenced
from local clones.
Suggested-by: Dave DeMarle <dave.demarle@kitware.com>

The "Review a Merge Request" section primarily depends on comments made
in GitLab.  Link from this section to the GitLab markdown documentation.
In particular, the special reference syntax options will be very
helpful.

Move use of the "Submit merge request" button to the last step.  Add a
step for the "Title" field before the "Description" field.  In the
"Description" field, split various hints into bullet points to make them
more distinct.  Provide a complete example of a description.  Explicitly
state that the other fields may be left blank.

Also mention in the "Review a Merge Request" section that "@" syntax
presents completion.  It is better to use completion there than in the
Description field because it will complete developers with access to
the target repository instead of just the source repository.
Inspired-by: Ben Boeckel <ben.boeckel@kitware.com>

Port instructions from the http://www.vtk.org/Wiki/VTK/Git wiki page to
Markdown documents in the source tree.  Update the instructions to work
for the GitLab environment.