Method to transform FluxPoints to stingray.Lightcurve

[cgalelli]

This draft PR introduces a basic method for transforming a FluxPoints object to a stingray.Lightcurve object. Only objects with format="lightcurve" and one energy bin are allowed.

This could give access to hybrid workflows (at least one way) between the two packages.

[bkhelifi]

`stringray' is not a dependency of Gammapy. One should then mention in the docstring that is uses it (then pip install) or to discuss the possibility to add this library into our dependencies.
If we keep it as optional, the import of the library should be made in the code and protected.
PS: and this is the primary cause of the failure of the tests ...

[cgalelli]

@bkhelifi I am well aware that stingray is not a dependency; this PR inserts itself in the larger discourse about whether to add it or not. It is mostly a proof-of-concept of how a translator (in one direction) would work in case we decide to add it.

[adonath]

@cgalelli How different is the stingray light curve format from the one from Astropy? (see https://docs.astropy.org/en/stable/timeseries/index.html)

[cgalelli]

@adonath stingray provides three different "Time series"-like objects: stingray.StingrayTimeseries (the most similar to astropy time series), stingray.Lightcurve (with most utilities for variability and analysis in general) and stingray.EventList (for unbinned or photon-to-photon analyses). stingray.Lightcurve shares many similarities with the astropy object, and there is in fact a translator provided by stingray itself; however it has some specificities that would render a "double translation" quite tricky.

[AtreyeeS]

Maybe this motivates further the need for a gammapy Lightcurve object inheriting from FluxPoints, which can support a format=stringray option?