Improve handling of circuit execution providers

[wshanks]

This change improves several aspects about the way ExperimentData works with "providers." Here "provider" is generalized beyond qiskit.providers.Provider to any object which can provide a Job-like object with data about an experiment's circuit execution. This generalization is needed because qiskit-ibm-runtime, the main provider that Experiments integrates with, does not use the Provider class, so

• Replace references to qiskit.providers.Provider and qiskit.providers.Job with custom interface definitions using typing.Protocol. The new interfaces document the API Experiments needs for working with these objects.
• Improve type hints and type checking related to providers, jobs, and results, using the new protocol classes.
• Infer IBMExperimentService authentication parameters from a qiskit_ibm_runtime.QiskitRuntimeService instance in the same way that the inference used to work with qiskit_ibm_provider.IBMProvider.
• Delay inferring an IBMExperimentService from a backend or provider until ExperimentData tries to communicate with the experiment service. With the fix to infer the authentication parameters from QiskitRuntimeService, this delay is needed to avoid breaking existing code that creates an ExperimentData instance and then tries to set a custom experiment service for it, relying on the fact that inferrence did not work for QiskitRuntimeService, since setting the service on ExperimentData after it has already been set once raises an exception.
• Remove dead code, both helper functions that are not called anywhere in the repository and code paths only relevant to qiskit-ibm-provider, like references to time_per_step(). Since qiskit-ibm-provider has long been deprecated and unsupported by IBM Quantum, removing support for it is not treated as a breaking change.
• Handle some optional data types better (like result objects that might have a metadata attribute).

[wshanks]

I wasn't sure if it was convenient to use the Job and Provider names here (they basically mean what you expect them to mean) or confusing (they don't quite mean exactly what you might first assume they mean). Maybe JobLike and ProviderLike would be better or something like that?