Issue 179 compilation speedup PIMPL

[SinYita]

This PR introduces PIMPL as we talked in meetings, reducing the cost of parsing heavy header files like Thrust during compilation of various codeobjects. Specifically: objects_storage.h holds the actual Thrust container. The lean objects.h exposes raw pointers (such as dev_array_* / host_array_*). And the newly generated objects_api.h inside device.py provides resize/clear/copy, eventspace extensions, and wrappers for some algorithms and cuRAND-related code previously scattered across other TUs. Most .cu files access data via raw pointers and the API, concentrating Thrust usage primarily in objects.cu.

Pointers:

sync_all_dev_ptrs() is called once at the end of _init_arrays() for a full refresh. If the container is modified via the API (such as resize_*), only the relevant pointers are synchronized. Therefore, as long as mutates use the API, the global PIMPL pointer can remain consistent with the container. The trade-off is the generation of a large number of API symbols in arrays(which is quite ugly right now). A more general template could be considered later to reduce the amount of generated code. And also I haven't apply PIMPL also for host vector, which will be add soon in following commits.

Outcome

On MushroomBody (N=1000), cold compilation with make -j1 is reduced to approximately ~100s (compared to approximately ~200s on master under the same environment RTX3080Ti 12GB).

[SinYita]

@mstimberg Hi Marcel,I am wondering If Thrust is indeed the main bottleneck—and given that we only use a limited set of its features (mainly host/device vectors and copy_if)—would it make sense to replace these with lightweight custom implementations? That way, we could avoid adding extra architectural complexity and significantly reduce compilation overhead. What do you think?

[mstimberg]

@mstimberg Hi Marcel,I am wondering If Thrust is indeed the main bottleneck—and given that we only use a limited set of its features (mainly host/device vectors and copy_if)—would it make sense to replace these with lightweight custom implementations? That way, we could avoid adding extra architectural complexity and significantly reduce compilation overhead. What do you think?

Maybe! Currently, our DynamicArray and DynamicArray2D implementations are thin wrappers around std::vector, but implementing them without std::vector shouldn't be terribly hard, either.