Automoc: Fix automoc for OBJECT libraries.

Before this patch,
add_library(obj OBJECT helper.cpp)
add_executable(tgt $<TARGET_OBJECTS:obj>)
didn't run automoc on helper.cpp.
Automoc: add OBJECT library to QtAutomoc test
ExternalProject: Allow DEPENDS on normal targets (#13849)

The ExternalProject_Add DEPENDS option adds two types of dependencies.
It adds a target-level build order dependency between the external
project target and the named targets.  It also adds a file-level
dependency on the "done" stamp file of the named external project
targets.  Targets not created by ExternalProject_Add have no such stamp
file and no _EP_STAMP_DIR property.  Prior to commit d14c0243 (Refactor
repeated code into function, 2012-04-26) we unconditionally accepted an
empty stamp dir and generated a dependency on a non-existent file.
After that commit we generate an error that no stamp dir is set.

Skip the file-level dependency when the named dependency is not an
external project target in order to allow this use case.  Teach the
ExternalProject test to cover the case.
VS11: Fix VSExternalInclude test

Set CMAKE_SUPPRESS_REGENERATION in the Lib1 and Lib2 projects so that
their .vcxproj files do not contain references to ZERO_CHECK.  Such
references do not make sense when using the files in another .sln file.
This does not reduce the effectiveness of the test because real projects
that use include_external_msproject will have their own .vcxproj files not
generated by CMake anyway.
Make sure generator expressions can be used with target_include_directories.

Handle the case that a generator expression is used before treating
a non-target as an error.
Populate the link information cache before checking dependent properties.

The dependent properties check can require the link information.
Add the $<TARGET_POLICY> expression

This new expression allows checking how a policy was set when a target
was created.  That information is only recorded for a subset of policies,
so a whitelist is used.
Exit early if we find an inconsistent property.

Further messages about inconsistency are distracting.
XCode generator won't infinitely parse compiler flags (bug #13354).

When parsing the compiler flag list we reduce the search space on
each iteration to be the subset of the string we hadn't searched
before.
Don't wrap all targets in LINK_LIBRARIES in a TARGET_NAME genex.

It is not necessary and the current state is unintentional. Before
this patch,

 target_link_libraries(foo bar)

causes the LINK_LIBRARIES property of foo to contain

 $<TARGET_NAME:bar>

instead of just

 bar
Make INTERFACE determined properties readable in generator expressions.

The properties are evaluated as link-dependent interface properties when
evaluating the generator expressions.
Generate new-style cmake code during export.

Use empty end*() commands and lowercase commands.
Clear the link information in ClearLinkMaps.

The cache here needs to be cleared if GetLinkInformation is called
at configure-time, such as during an export().

The next commit does exactly that, and without this patch,
the LinkLanguage test would fail.
Export the COMPATIBLE_INTERFACE_BOOL content properties
Store includes from the same include_directories call together.

Otherwise, we get a separate IncludeDirectoriesEntry for each include,
and that causes unnecessary and confusing splitting in the output when
debugging the INCLUDE_DIRECTORIES property.
Only output includes once after the start of 'generate-time' when debugging.

During configure-time, GetIncludeDirectories may be called too, for example
if using the export() command. As the content can be different, it should
be output each time then.
Specify the target whose includes are being listed.
Output include directories as LOG messages, not warnings.
Revert "Allow target_link_libraries with IMPORTED targets."

This reverts commit 9cfe4f1b769597bd9ba179eba46572a9df27f64c.

It turns out that correctly adding the content to
the IMPORTED_LINK_INTERFACE_LIBARIES_<CONFIG> of an upstream target
from the buildsystem of a downstream project is not simple.

If upstream had added the INTERFACE content, the config-specific
properties would  be determined by the DEBUG_CONFIGURATIONS of
upstream.

As downstream, we don't have any information about what
the DEBUG_CONFIGURATIONS of upstream were, so we can't determine
which configuration-specific properties to populate. The best we can do
is add it to all of them or add it to the ones downstream considers to
be DEBUG_CONFIGURATIONS, neither of which is a good solution.

So, removing the porcelain API for that is the best approach. A human
can still determine which properties to populate and use
the set_property API to populate the desired properies.

Another solution to this would be for upstream targets to publish
what they consider DEBUG_CONFIGURATIONS, but that can be added in
a future release.
Disallow porcelain to populate includes and defines of IMPORTED targets.

With similar reasoning to the parent commit, as downstreams, we can't
determine what $<CONFIG> generator expressions would be appropriate.

Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
config-specific generator expressions, possibly appropriate for
their DEBUG_CONFIGURATIONS. In theory, if we would add include
directories for a DEBUG intent, we would have to match the upstream
configurations for that.

Rather than attempting to discover the appropriate configurations
at this time, simplify the feature instead. The use of IMPORTED targets
with these commands could still be added in the future if targets
would export their DEBUG_CONFIGURATIONS somehow.