[C++] Use the CMake's standard find features

[asfimport]

From #3469 (comment)

We implement our custom find codes to find libraries by find_library()/find_path() with NO_DEFAULT_PATH. So we need to handle lib64/ (on Red Hat) and lib/x86_64-linux-gnu/ (on Debian) paths manually.

If we use the CMake's standard find features such as CMAKE_PREFIX_PATH https://cmake.org/cmake/help/v3.13/variable/CMAKE_PREFIX_PATH.html#variable:CMAKE_PREFIX_PATH , we can remove our custom find codes.

CMake has package specific find path feature by <PackageName}_ROOT since 3.12. It's equivalent of our <PackageName}_HOME.

https://cmake.org/cmake/help/v3.12/command/find_library.html

If called from within a find module loaded by find_package(<PackageName>), search prefixes unique to the current package being found. Specifically look in the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment variable. The package root variables are maintained as a stack so if called from nested find modules, root paths from the parent’s find module will be searched after paths from the current module, i.e. <CurrentPackage>_ROOT, ENV\{<CurrentPackage>_ROOT}, <ParentPackage>_ROOT, ENV\{<ParentPackage>_ROOT}, etc.

Reporter: Kouhei Sutou / @kou
Assignee: Uwe Korn / @xhochy

Subtasks:

• [C++] Add support for system GFlags

Related issues:

• [C++] Rework CMake third-party logic (is a child of)
• [C++] Please have a cmake variable to build with all externally installed dependency packages (relates to)

_{Note: This issue was originally created as ARROW-4383. Please see the migration documentation for further details.}

[asfimport]

Wes McKinney / @wesm:
What do you think about trying to find the cmake/package-config.cmake file in our FindPACKAGE.cmake files and then fall back on the existing logic if the cmake files are not found? We are already using these for double-conversion, for example, but it would be good to do so consistently.

[asfimport]

Kouhei Sutou / @kou:
I agree with the idea that we use find_package() with CONFIGS as the first try.

This is not a scope of this issue but I want to change the current vendored strategy. I want to change to use the system libraries by default and vendored libraries as fallback (and option). Now, we use vendored libraries by default. (e.g.: double-conversion)
If we can use the system libraries by default, users don't need to build existing libraries by default.

[asfimport]

Wes McKinney / @wesm:
I suggest we address this more comprehensively after ARROW-4611 is in

[asfimport]

Kouhei Sutou / @kou:
I think that ARROW-4611 will resolve this too.
I'll check this again after ARROW-4611 is merged.

[asfimport]

Uwe Korn / @xhochy:
Resolved by PR #3688