Add experiment_metadata to analysis

[nkanazawa1989]

Summary

Base experiment supports an overridable method to provide experiment metadata, which is often useful to communicate with analysis classes. This PR adds experiment_data method to BaseAnalysis so that every subclass can easily access to this metadata.

Details and comments

Follow up; In principle, analysis class doesn't need to take full ExperimentData object because this object also has unnecessary mechanism for remote database access and job control. Thus, it's sufficient for analysis to take ExperimentData.data() and ExperimentData.metadata. New mechanism allows BaseAnalysis._run_analysis to run analysis with experiment metadata, without taking full experiment data object.

Two experiments and analysis have been updated to showcase how new property can be used.

[wshanks]

The T2Ramsey and CrossResonanceHamiltonian examples help explain the motivation for this PR. The goal is to communicate more information from the experiment run to the analysis class, in particular to CurveAnalysis subclasses. For a generic BaseAnalysis subclass, the ExperimentData metadata is already accessible in _run_analysis because ExperimentData is the argument to _run_analysis. However, for a CurveAnalysis subclass it is typical to define the fit model in __init__ and to override only _default_options, _generate_fit_guesses and _evaluate_quality (there are a few others but those are the main relevant ones). The methods only get some form of data at the moment (nothing for options, processed for the guesses, and fit results for the quality), but they could benefit from metadata about the experiment, like the T2Ramsey example of knowing what the applied virtual frequency is for determining the frequency offset.

This PR captures the metadata from the ExperimentData into a property of the analysis class so all methods of the class can access it. The main concern that I want to flag for @chriseclectic is that I think there is a design goal for BaseAnalysis not to be stateful, so it can be created once and then run on ExperimentData instances without side effects. That is kind of still the case here since each run call will overwrite the metadata (but the metadata setting probably needs to be moved down into the callback to avoid problems with multiple experiments using the same analysis instance and overwriting each other's metadata, though in the default flow each experiment would get its own analysis so this wouldn't come up). One thing to note is that RBAnalysis already does something like what this PR does by storing the physical_qubits entry from the ExperimentData metadata into a class attribute.

Some alternatives to storing the metadata in BaseAnalysis would be to store it in BaseCurveAnalysis._initialize (since it is mainly a CurveAnalysis issue) or to just pass the metadata from method to method in CurveAnalysis (requires more refactoring/disruption of existing code). Or we could just decide the RBAnalysis approach is okay -- just grab the metadata in _initialize and store it somewhere for later use without the BaseAnalysis or CurveAnalysis base class defining a preferred approach to capturing the metadata.

[CLAassistant]

All committers have signed the CLA.