This retains the desirable quality of not including paths to CUDA libraries
from the build system into the config files, and has two major advantages:

* It removes the need to use link_directories, which doesn't guarantee that
  the libraries from the supplied directory will be used (there may be
  libraries with the same names earlier in the search path).

* It removes the need to put -L entries into OPENCV_LINKER_LIBS. This variable
  is used with target_link_libraries, where such entries are treated as linker
  flags, so doing this is unportable. I remove the support for -L entries
  from OpenCVGenPkgconfig.cmake, as well, to discourage adding them in the
  future.

There's no reason to do it twice.

Explicitly linking to a Python framework on OS X prevents modules from
being built against one python (i.e. system python) and imported from
another (i.e. Homebrew python); the interpreter segfaults if there's a
linkage to a foreign python. Building the module with `-undefined
dynamic_lookup` instead of an explicit link allows the symbols to be
resolved at load time from a compatible python.

A difference of two pointers was casted to unsigned which can lead to
overflow on 64-bit systems.

Make detection of x64 using the gcc's target triplet identical
to the one used in cmake/OpenCVDetectCXXCompiler.cmake.
Otherwise, MinGW-w64 setups will always be treated as x64 since
they contain "w64" as vendor key.

Fix typo that would always lead to detection of x86 for MinGW
builds in the OpenCVConfig.cmake file.

Add all dirs from CUDA_LIBS_PATH as -L linker options to
OPENCV_LINKER_LIBS. These will end up in opencv.pc.

previous implementation was not thread/stream safe, since it used constant
memory

new implementation doesn't use any global objects, so it is thread/stream safe