Add package for cmake project

[ruffsl]

This PR simply adds a package.xml used for build tools like catkin or colcon, allowing for the essential build dependencies to be readily identified and when scheduling build order from dependency graphs.

[alalek]

Some guide/link how to use that would be extremely useful.

Platform-specific files should be placed under the "platforms" directory: https://github.com/opencv/opencv/tree/master/platforms

• here is Maven stuff
• here is JavaScript stuff
• and this one should go there too (probably with CMakeLists.txt wrapper)

[alalek]

Is this list really complete?

[ruffsl]

As @mikaelarguedas #16322 (comment) pointed out, we could specify more of the optional dependencies, I just wasn't sure to what extent we'd like to include them explicitly as required, though the one linked seems like a more practical useful build for general users.

[asmorkalov]

@ruffsl friendly reminder

[mikaelarguedas]

@ruffsl If it's useful, we used the following package.xml files to package opencv in ROS Lunar in the past: https://github.com/ros-gbp/opencv3-release/blob/3ffcbb05e149676d9f92a5d66c3f4b5da42962d7/lunar/package.xml (this was for opencv 3.3.1 at the time)

[ruffsl]

Some guide/link how to use that would be extremely useful.

Sorry, here is some more context as per the motivation and rationale for include a package manifest for summarizing the package depencies, licensing, etc:

Package Manifest Format Three Specification:
https://www.ros.org/reps/rep-0149.html

Platform-specific files should be placed under the "platforms" directory

This package manifest is os or platform agnostic, we use them in ROS for cmake packages built on windows, linux, macos.. and is necessarily located in the same directory as the root CMakeLists.txt for the project. But perhaps we could iterate on alternative idea for its location. Perhaps a fancy cmake file placed in its own platform folder that would point back to root level CMakeLists.txt file.

[alalek]

I believe, dedicated place/repository for package manager configuration is preferable, than pushing these configurations into upstream reporsitory.

Mixing upstream source code with packaging details of specific package manager doesn't look as a good idea. All package managers and/or their build configurations have own specific stuff.

Refer to multi-platform homebrew, vcpkg, conda package managers or even Linux distros (Ubuntu / Fedora / Arch / etc).

---

<package format="2">

REP-0149 says about format="3". It is hard to support multiple versions in upstream repository.

---

/cc @vrabaud as contributor of OpenCV and https://github.com/ros-gbp/opencv3-release repository.