More features to the z-t converters

[MaxThevenet]

Laser.export_to_z and Laser.import_from_z do proper conversions between Z and T representations. Some additions would make it useful:

• Include the I/O handling so LASY can output Z and T representations
• Include the I/O handling so LASY can input Z and T representations
• Allow dummy conversion (z = -ct) and decide on where the 0 is
• Maybe this could be put to utils? That would lighten the Laser class, but might be cumbersome, not sure.

[hightower8083]

Concerning the last point, I would move propagate and converters (all axiprop-dependent stuff) to an utility class somewhere separate (e.g. propagate_util.py) and is inherited by lasy. This can also be joined with #164, as in case of non-installed axiprop, this class is replaced with a dummy, so these methods will simply not appear in the lasy object and we can avoid these multiple assert axiprop_installed conditions.

[MaxThevenet]

I think whether we do a dummy z-t conversion or a full clean conversion using axiprop should be independent on whether axiprop is installed. For FBPIC -> LASY -> Wake-T workflow, we will always do the dummy conversion as it is more accurate. So the options I see are:

1. put all in laser_utils.py, and keep the assert axiprop_installed somewhere. If that could be manageable, I would prefer it this way, so that we always call convert_z_to_t (or whatever name), as it is the same operation, and pass an argument whether it is dummy.
2. just have 2 functions: convert_z_to_t and convert_z_to_t_dummy (and same for t_to_z).

I would have a preference for the first one, as it should be slightly easier to use and compare both, but either works.