664 missing assertions for threaded execution

[byjtew]

Closes #278

[anyzelman]

Ready to merge

[GiovaGa]

@anyzelman this seems solved, I don't know if we want a clearer error message to be outputted instead of a possibly cryptic assertion error.
I will run unit tests on the internal CI just to be sure, but should be good to go

[anyzelman]

I rebased again, reviewed it, and running smoke + unit tests with LPF now (in addition to CI).

Changes during review: I made the check a function of the Coordinates class, as otherwise it is not easy to call for a check without a lot of code repetition. I also modified the internal::getCoordinates for const-coordinates to perform the check. I did not think the modification to config::OMP was needed and reverted that, instead relying on its already-established threads function call.

There is one annoyance that in the use of the coordinates class, a callee tends to call a third class for creating the buffer, and then passes that into Coordinates. This means that the number of threads is actually controlled by this third class. The current design in this MR is hence not totally robust if somehow the number of threads spawned during a parallel section changes between the time the third party class code executes and allocates the buffer for some T1 #threads , and the time the #threads is actually recorded when the coordinates instance is set while some other T2 #threads is active.

[anyzelman]

Concept release notes (all unit tests with LPF still running on the latest commit):

Benjamin (@byjtew) noticed, once upon a time, that should users manually modify the number of threads available to OpenMP while the application is running, the application could crash without a clear error message. This issue recently resurfaced and this MR fixes at least some instances of this by implicitly checking if thread-counts remain the same whenever the sparse accumulator (SPA) of vectors or sparse matrices is retrieved. This check, however, has non-trivial overhead and is only active in debug mode. The end-user advice hence, as always, is to enable debug mode should their application crash for unclear reasons.

This MR also includes a performance improvement to advancing iterators over ALP/GraphBLAS vectors, which was done in the context of this MR as otherwise the debug-mode unit tests took too much time. However, this performance improvement should also benefit performance-mode code as it holistically speeds up iteration. It also includes minor code style fixes and internal documentation improvements.

The implementation of the check is constrained in that it assumes thread counts will not change between allocating SPA buffer data and assigning that buffer to a SPA. While the ALP internals guarantee that no such change occurs from within ALP, it is conceivable that such a run-time thread-count change could be concurrently initiated by a user thread, which in turn could be timed unfortunately so that this assumption is indeed violated. We consider this a rather adversarial case that would not be worth the implementation effort to guard against, but do note this caveat here in the commit notes.

Thanks also to @GiovaGa for recently revisiting this MR and again to Benjamin for flagging the issue and providing the initial fix, now finally merged.

[anyzelman]

All tests OK, merging