Add BackendV2 abstract class

[mtreinish]

Summary

This commit adds a new abstract class that adds a new version of the
backend abstract class. The primary changes being made in this class are
that instead of using BackendConfiguration for immutable characteristics
of the backend those are instead exposed as read only attributes of the
Backend object itself. This also takes some time to improve how we
represent some core data about a backend. The primary example of this is
that basis gates are no longer a list of names but contained inside a new
Target class which represents a compiler target for Qiskit.

Details and comments

TODO:

• Add optional attributes for common pulse and timing configuration properties, we need to decouple what IBMQ returns from a common set of properties. (IBMQ backends can still return extra fields which are IQX specific, not everything needs to be in the base class only things that the rest of terra needs)
• Come up with an interface for properties, including figuring out a native object model to use (not a python object mapping the iqx api format like BackendProperties) for representing the data
• Come up with a similar interface for pulse defaults

Longer term follow ups (these will need to be handled in a backendV3 and JobV2):

• Add job manager concept for splitting jobs automatically
• Add support for running parameterized circuits with a bind table
• Based on Add defined phases to the PassManager #5978 add support for transpiler hooks in a backend (ie having transpiler passes in a backend object)
• Standardize mechanism for discovery of backend result type (statevector vs unitary vs counts, etc)
• We should start update the data model used in the pass manager to assume Gate and Instruction objects instead of names

[ajavadia]

Let's discuss how we can define an instruction set to cover #5774, and to replace the following with something general:

• config.basis_gates
• config.supported_instruction
• config.custom_instruction (Aer)
• config.gates

[ajavadia]

Add job manager concept for splitting jobs automatically

This seems like a provider responsibility. The backend should just run what is given to it.
I think we should move towards making the backend simpler not more complicated. The most basic backend.run() implementation should be to just run a single circuit. Note that some backends don't even allow running multiple circuits (qiskit-community/qiskit-ionq#70). If the provider wants to allow multi-circuit runs, then great, but that should be built as something separate to backend.run() I think. It will be a breaking change, but since it's V2 I don't feel too bad about it :)