Break the DIALS/xfel circular dependency

[phyy-nx]

DIALS and dxtbx have had dependencies on cctbx_project/xfel, and vice versa. This PR is one of 8 (!) that will all be merged in simultaneously to 8 repositories to break the cyclic dependency.

Brief summary:

• A new top level project in cctbx_project has been created: serialtbx
• Any code needed by DIALS and dxtbx that was in xfel has been moved to serialtbx or directly into DIALS/dxtbx. That mostly includes code to read data at XFELs used by dxtbx, and stills-specific indexing/integration methods.
• serialtbx has no imports of DIALS or dxtbx and so it can be directly configured by the conda packages cctbx and cctbx-base, @bkpoon. That said, there are no dispatchers or libtbx_config file so nothing specifically needs to be done to bootstrap.py, I believe.
• All imports of xfel in DIALS and dxtbx have been updated to use the new serialtbx or DIALS/dxtbx imports
• All other known repos that have xfel imports have been updated to use the new serialtbx or DIALS/dxtbx imports
• xfel will remain configured in the DIALS binary bundles on dials.github.io and distributed by phenix. For conda, the plan is to make a cctbx.xfel conda package that includes all its dependencies (MPI, MySQL, etc.)

All tests pass on my local test machine (DIALS, dxtbx, and XFEL CI).

Se also cctbx/dxtbx#627 and dials/dials#2404

Detailed listing of code movements:

• xfel.util.jungfrau → serialtbx.detector

From xfel.cftbx.detector:

• cspad_detector → serialtbx.detector.legacy_metrology
• generic_detector → serialtbx.detector.legacy_metrology
• metrology → serialtbx.detector.legacy_metrology

From xfel.mono_simulation:

• max_like → serialtbx.mono_simulation
• util → serialtbx.mono_simulation

From xfel.cftbx.detector.cspad_cbf_tbx:

• Constants moved to serialtbx.detector.cspad
• get_psana_corrected_data → serialtbx.detector.cspad
• cbf_wrapper → merged with dxtbx.format.FormatCBFMultiTile.cbf_wrapper
• angle_and_axis → dxtbx.format.FormatCBFMultiTile.cbf_wrapper
• center → serialtbx.detector
• basis → serialtbx.detector
• basis_from_geo → serialtbx.detector.xtc
• read_slac_metrology → serialtbx.detector.cspad
• add_frame_specific_cbf_tables → dxtbx.format.cbf_writer

From xfel.command_line.cspad_detector_congruence:

• iterate_detector_at_level → serialtbx.detector
• iterate_panels → serialtbx.detector
• id_from_name → serialtbx.detector
• get_center → serialtbx.detector

From xfel.command_line.frame_extractor:

• ConstructFrame → serialtbx.util.construct_frame

From xfel.cxi.cspad_ana.cspad_tbx:

• Constants moved to serialtbx.detector.cspad
• address_split → serialtbx.detector.xtc
• dpack → serialtbx.detector.cspad
• get_ebeam → serialtbx.detector.xtc
• env_distance → serialtbx.detector.xtc
• evt_wavelength → serialtbx.detector.xtc
• env_detz → serialtbx.detector.xtc
• old_address_to_new_address → serialtbx.detector.xtc

From xfel.cxi.cspad_ana.rayonix_tbx.py:

• Constants moved to serialtbx.detector.rayonix
• get_rayonix_pixel_size → serialtbx.detector.rayonix
• get_rayonix_detector_dimensions → serialtbx.detector.rayonix
• get_data_from_psana_event → serialtbx.detector.rayonix

C++ code from xfel/ext.cpp:

• radial_average → dxtbx.ext

From xfel.util:

• sublattice_helper → dials.algorithms.integration

[phyy-nx]

How 'bout that. The tests all passed :)

This is ready for review!

[phyy-nx]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 3 pipeline(s).

[phyy-nx]

Test expected to fail right now as they depend on the dials and dxtbx PRs (cctbx/dxtbx#627 and dials/dials#2404).

[ndevenish]

Minor thought: do you think it would be worth doing in two phases, adding the serialtbx sections searately, before updating xfel? It would save any sticky disentanglement if things go wrong up/downstream.

[phyy-nx]

Ah, you mean add the serialtbx changes only, and do code removal from xfel in a separate pass? Not a bad way to go, but I think the testing should have caught any problems. I'll run the tests again today to be sure.