Add option to use OneTBB for multithreading

[jdumas]

It'd be great to be able to use OneTBB as the multithreading backend. Using the same scheduler in a larger app really helps avoiding oversubscription in general. When I was at nTopology I did some work in this direction in our geogram fork at the time (using an older TBB version). Maybe this can provide some inspiration. One important change is that TBB's spinlock cannot be initialized with an assignment constructor (foo = x syntax), so this requires a few extra changes in the rest of Geogram.

[BrunoLevy]

I have in mind two things:

• for spinlocks, replace them with std::atomic. Do you have an experience with it ? I don't know whether it is efficiently implemented in the compilers (I'll take a look at the generated asm when I have time)
• geogram's thread manager is abstracted, so it would be easy to have a OneTBB implementation

[jdumas]

I think std::atomic should be generally faster than any mutex implementation, but it really depends on the usage, so one would need to profile to be sure. TBB has its own spin_mutex implementation, among many other flavors. They have a page that explains the different flavors and how they scale wrt to each others. I am not familiar enough with them to know which one would be more suited for Geogram.