FeatureSummary: Don't list transitive package dependencies

Set a global property in the find_package implementation.  Track and
reset that property in the find_dependency macro.  Read the property
in FeatureSummary when determining whether to print output.

This means that packages which are found only as dependencies are not
listed by FeatureSummary, but if a project uses find_package elsewhere
directly, then it will be listed by FeatureSummary.

Suggested-by: Alex Merry

 http://thread.gmane.org/gmane.comp.kde.devel.frameworks/10640
Help: Be clearer about which header files are considered for AUTOMOC

The old documentation stated that "all header files" were considered,
which was not true for any sensible definition of "all header files".
Only header files with certain names are considered.

Document the filename patterns matched for parsing.
Utilities/Sphinx: Add option to build 'text' format

Add SPHINX_TEXT to enable the Sphinx 'text' builder.  Mark it as
advanced and do not add install rules.  This is intended for use
by the release manager to build the release notes in text format
suitable for email.
Help: Add documents for release notes

Add a release/index.rst document titled "CMake Release Notes" to hold
the toctree for release notes.  Add a "Release Notes" section to the
top-level html document index to link to the new document.
Help: Add documents to collect notes between releases

Add a release/dev.txt file and include it from release/index.rst in
development versions.  Add a "Changes Since Release" section with a
toctree that globs adjacent "dev/*" documents.  Add a sample topic
document explaining how topic-specific release note documents work.

This approach will allow developers to write release notes for their
changes as they are made.  The release manager may then consolidate and
organize the notes for a specific release version.
Drop tweak version component from CMake Policies

Since commit v2.8.2~105^2~2 (Teach CMake Policies about tweak version
component, 2010-04-23), cmPolicies has known how to handle a policy
introduced in a tweak version.  This was done back when we introduced
policies with the current development date version and later updated it
to the release version.  Now we always introduce policies using the next
expected release version and explicitly set the policy to test the NEW
behavior.

CMake Policies (or any other features) should never be introduced in a
tweak (bugfix) release, so drop the infrastructure that allows this.
Help: Expand documentation of CMAKE_VERSION and related variables

Describe the meaning of each version component in more detail in the
documentation of CMAKE_VERSION.  Simplify the per-component version
variable documentation by referencing the main variable.

Include information about how to compare version strings.  Also add
an historical note about the version scheme used prior to commit
v2.8.2~105^2~4 (New version scheme to support branchy workflow,
2010-04-23).
Merge topic 'FeatureSummary-no-transitive'

a6971f65 FeatureSummary: Don't list transitive package dependencies
Merge topic 'AUTOMOC-docs'

635e96dd Help: Be clearer about which header files are considered for AUTOMOC
Merge topic 'release-notes'

ccc87047 Help: Add documents to collect notes between releases
70309e70 Help: Add documents for release notes
34ea1f15 Utilities/Sphinx: Add option to build 'text' format
Merge topic 'no-policy-tweak-version'

101057b5 Drop tweak version component from CMake Policies
Merge topic 'doc-version-components'

52e7beb6 Help: Expand documentation of CMAKE_VERSION and related variables