Add cmGeneratorExpression::Split() API.

It can split a string like

 "A;$<1:B>;$<1:C>;D;E;$<1:F;G;H>;$<1:I>;J"

into

 "A" "$<1:B>" "$<1:C>" "D" "E" "$<1:F;G;H>" "$<1:I>" "J"
Keep track of properties used to determine linker libraries.

Those properties can't later be implicitly defined by the interface
of those link libraries.
Add API to calculate link-interface-dependent bool properties or error.

This new method checks that the property FOO on a target is consistent
with the INTERFACE_FOO properties of its dependees. If they are not the
consistent, an error is reported. 'Consistent' means that iff the
property is set, it must have the same boolean value as all other
related properties.
Process the INTERFACE_PIC property from linked dependencies

This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Don't pass a position when determining if a target name is a literal.

The lastPos refers to a position in a different string.
Extract the AddTargetNamespace method.
Split the generator expression before extracting targets.

Now that we're processing a LINK_INTERFACE_LIBRARIES string, it
can contain targets. Make sure they are extracted for
namespacing purposes.

This needs to be restricted to strings which can actually have
targets named in them. For example, this is not done for
INTERFACE_COMPILE_DEFINITIONS, because even if there is a target
named 'foo', the string 'foo' in that property means that '-Dfoo'
will be set when compiling.
Split LINK_INTERFACE_LIBRARIES export handling into dedicated method.
Allow generator expressions in LINK_INTERFACE_LIBRARIES.

The Config and IMPORTED_ variants may also contain generator
expressions.

If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.

1) In the case of non-static libraries, this is fine because the
  user still has the option to populate the LINK_INTERFACE_LIBRARIES
  with generator expressions if that is what is wanted.

2) In the case of static libraries, this prevents a footgun,
  enforcing that the interface and the implementation are really
  the same.

  Otherwise, the LINK_LIBRARIES could contain a generator
  expression which is evaluated with a different context at build
  time, and when used as an imported target. That would mean that the
  result of evaluating the INTERFACE_LINK_LIBRARIES property for
  a static library would not necessarily be the 'link implementation'.

  For example:

    add_library(libone STATIC libone.cpp)
    add_library(libtwo STATIC libtwo.cpp)
    add_library(libthree STATIC libthree.cpp)

    target_link_libraries(libtwo
      $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
    target_link_libraries(libthree libtwo)

  If the LINK_LIBRARIES content was simply copied to the
  IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
  executables linking to libthree will not link to libone.

3) As the 'implementation is the interface' concept is to be
  deprecated in the future anyway, this should be fine.
Merge topic 'LINK_INTERFACE_LIBRARIES-genex' into next

ae55193 Allow generator expressions in LINK_INTERFACE_LIBRARIES.
20e6daf Split LINK_INTERFACE_LIBRARIES export handling into dedicated method.
c110bd1 Split the generator expression before extracting targets.
d0094bd Extract the AddTargetNamespace method.
9305c9f Don't pass a position when determining if a target name is a literal.
b36471b Add cmGeneratorExpression::Split() API.
Merge topic 'INTERFACE_POSITION_INDEPENDENT_CODE' into next

dc4152a Process the INTERFACE_PIC property from linked dependencies
042ecf0 Add API to calculate link-interface-dependent bool properties or error.
bf5ece5 Keep track of properties used to determine linker libraries.