279 bug in move assignment of matrices

[byjtew]

Closes #279

[anyzelman]

Hi @byjtew @aleksamilisavljevic could you have a look at the rfc? The first is easy, the second is a little bit tricky to think about-- is the suggestion ok or am i missing something?

[anyzelman]

Concept release notes:

Aleksa uncovered a bug where move-assigning matrices could result in container IDs not explicitly being removed. Since IDs are created on the basis of unique keys and the unique keys are derived from pointers, the following could (and did) happen: on creating a new matrix, a new ID is requested based on the same pointer the retained ID was also created with. This was detected by the internal mechanism keeping track of IDs, and resulted in an exception.

This MR fixes the bug by removing the ID once the container with the original pointer is destroyed via a move. Even if a subsequent allocation then happens to return the same pointer, the internal state is now clean and a new ID is successfully derived. The MR also strengthens the getID unit test to have been able to detect this issue.

The MR also includes a hotfix for an issue detected by our internal CI: on defining full debug tracing (-D_DEBUG), various BSP1D code did not compile-- herewith fixed as well.

Finally, this MR and now again fully related with the issue at hand, improves on _DEBUG tracing in bsp1d/matrix.hpp, and fixes a similar issue for the BSP1D backend: there, prior to this MR, move-assignment would result in never-deleted IDs and a small memory leak. Because of the memory leak, the bug never materialised in the same way it did for the reference backend, though nevertheless with this MR now correctly removes the ID as part of a move-assign and prevents the memory leak.

Thanks to Aleksa Milisavljevic @aleksamilisavljevic for detecting and fixing this bug!

[anyzelman]

GitHub CI OK, manual unit tests with LPF and with _DEBUG OK-- will merge. Thanks @aleksamilisavljevic for contributing this one!