Added Before_Z_Hooks copy of AcqEngJ code.

[nicost]

I have no way of actually running or testing this code. Pycharm seems to think it will compile, except for the use of StrVector, which was not introduced by me. This is an effort to play by the rules, but I have to say that the bar of contributing to AcqEngJ is pretty high given the requirement to write the same code in two languages and test in two completely different environments.

[henrypinkard]

Thanks for this PR.

This is an effort to play by the rules, but I have to say that the bar of contributing to AcqEngJ is pretty high given the requirement to write the same code in two languages and test in two completely different environments.

Just to clarify, AcqEngPy and AcqEngJ do not need to be perfectly synchronized, and there aren’t separate sets of tests for each. All tests for AcqEngJ can be found within pycro-manager. While it’s beneficial to include tests with new features to ensure long-term stability, it’s not a strict requirement.

I find that writing tests in Python makes them more accessible to many in our community who know Python but not Java. Although it’s feasible to consider a separate Java test suite for AcqEngJ, setting up and automating the current system took a significant amount of work, and I don't have any plans to do the same for Java tests.

If you’re interested in developing additional tests in Java, that would certainly be valuable. More tests are always good!

I have no objections to you taking any of the approaches of 1) Write tests in python 2) Write new tests in Java 3) add new features without adding new tests. The only required thing is that new features don't break existing functionality. Sometimes this inevitably will require working in Python. I don't see how this can possibly be avoided in a multi-language project where different frontends rely on the same underlying modules