Add to IncrementalMapper reusage of Ceres internal context

[S-o-T]

Avoid costs for Ceres internal threadpool initialization at each bundle adjustment instance solve, by reusing Ceres internal context.

[ahojnnes]

Seems like this was only introduced in Ceres 2.1.X or later. However, colmap still supports older versions as well. Do you have any profiling results of what speed gains we can expect from this change? Depending on that, we could consider doing something special for newer ceres versions to benefit from this already today.

[S-o-T]

All the difference essentially comes from time spend on threads creation inside of ceres::internal::ContextImpl::EnsureMinimumThreads, so here are two histograms of its duration (in ns) for reconstruction of size 50 images (181 calls to ceres::internal::ContextImpl::EnsureMinimumThreads total). As can be seen, the distribution is bi-modal, where the heavier mode for the case of context reusage is much smaller.

Absolute wall time speedup is a function of the ba problem size, so it is application specific (num features, num cameras, tolerances, linear solver type etc). I would argue, that for most applications with default settings we should not bother with introduction of macro to account for various ceres versions. But if you believe that this kind of speedup can be valuable, i will work on this.

[ahojnnes]

Thanks for the profiling. I tend to agree that the speed gains are marginal compared to the total runtime of a BA. Maybe it looks more favorable if we reuse the context also across pose refinement. However, even there, the max runtime of 1 millisecond is negligible compared to multiple hundreds of milliseconds of total runtime. I'll keep this PR open as a reminder that we can make this improvement whenever support for older ceres versions is dropped (for now, Ubuntu 20.04 ships with ceres 1.14 and is still quite recent and widely used).