Legacy offline reconstruction C++ Runner

[yuecideng]

initialize the workflow for the whole system.

Will make it ready for review when complete the migration of python version and performance test.

Update: The whole system is nearly identical with python version of legacy reconstruction system, except the PoseEstiamtion part, where the python version uses opencv orb to find correspodences, and the cpp version uses fpfh to do this.

---

This change is 

[update-docs[bot]]

Thanks for submitting this pull request! The maintainers of this repository would appreciate if you could update the CHANGELOG.md based on your changes.

[yxlao]

We have some separate discussions today:

1. We can move the example to the cpp/apps folder, as this is larger scale than an "example". We are providing an "application" for people to use with many config options. When we move to the cpp/apps folder, it is possible to create multiple files, multiple headers, making the code more structured.
2. We can move most functionality to open3d::pipelines::reconstruction namespace. The main function in the cpp/apps folder only serves as argument parsing and driver for the code. The main processing is done inside open3d::pipelines::reconstruction.
3. After 2. is done, we shall be ready to pybind open3d::pipelines::reconstruction and make the python-based reconstruction pipeline to use the same code. This will reduce code duplication.

We can achieve these step by step. For this PR, we may do step 1 first. We can discuss the design of 2. and 3. in future meetings to design it, before actual implementation.

[theNded]

We have some separate discussions today:

1. We can move the example to the cpp/apps folder, as this is larger scale than an "example". We are providing an "application" for people to use with many config options. When we move to the cpp/apps folder, it is possible to create multiple files, multiple headers, making the code more structured.
2. We can move most functionality to open3d::pipelines::reconstruction namespace. The main function in the cpp/apps folder only serves as argument parsing and driver for the code. The main processing is done inside open3d::pipelines::reconstruction.
3. After 2. is done, we shall be ready to pybind open3d::pipelines::reconstruction and make the python-based reconstruction pipeline to use the same code. This will reduce code duplication.

We can achieve these step by step. For this PR, we may do step 1 first. We can discuss the design of 2. and 3. in future meetings to design it, before actual implementation.

I disagree with 2 and 3. Python itself has a lot of flexible packages, from configargparse to torch and numpy. They are good for fast prototyping and debugging. Python examples can be self-included and reusable as reconstruction system modules.

If we ship yet another C++ pybind layer upon the existing pipeline modules, to maintain the same usability, we have to spend 10x time on C++, while the users will probably still stick to native python packages. We have to composite docs which are already lacking.

IMO it is better to spend time on refining modularized pipeline components (odometry, integrate, slac) than adding another layer to the existing layers.

[yuecideng]

We can move the example to the cpp/apps folder, as this is larger scale than an "example". We are providing an "application" for people to use with many config options.

This is a good idea, and maybe we can add more interesting and reusable applications in the future. I would like to keep contributing in this part 👀 . But my concern is that, we also have some examples (both c++ and python) that are more like a application (eg. python legacy reconstruction, c++ online/offlone slam. etc). I think they should be moved to apps as well. So maybe we should create open3d/apps/python and open3d/apps/cpp? Just a suggestion, we could discuss this in meeting.

For 2 and 3, I'm also glad to discuss them and see the pros and cons of doing this.

[yuecideng]

1. Move LegacyReconstruction to cpp/apps folder and change name into OfflineReconstruction, which make it compatible wit h tensor based offline reconstruction in the future.
2. Seperate some helper functions into several header files to make the code more structured.
3. Currently the OfflineReconstruction command line executable can be found in /bin/OfflineReconstruction/. The output path I think should be designed for a better place.
4. Currently the installation is not supported.