Add `Target` representation to rust

[mtreinish]

What should we add?

An increasing amount of the transpiler is code is now living in rust and with that are core algorithms that need to reason about the various constraints of backends. So far this is just connectivity or various error rates, and we've been handling this by constructing various data containers in rust that contain the subset of information necessary for a particular algorithm. For example OneQubitGateErrorMap: https://github.com/Qiskit/qiskit/blob/main/crates/accelerate/src/euler_one_qubit_decomposer.rs#L37 in 1q peephole optimization, the neighbor table and distance matrix in sabre, and ErrorMap for vf2 scoring. In the near future we'll be adding additional algorithms where we'll need different error rate information from the target in rust too (see #11659 and #8774). All of this is basically just working around the lack of a native rust representation of the Target. So instead of continuing to add ad-hoc data structures like this instead we should work on making the core data structures of the base Target class exist in rust, so that whenever a target is created we automatically have the data in rust.

It's probably not feasible to replace the entire target class with a rust implementation, but we can have the internal data structures be rust structs that contain the data and the python class wraps those with the existing API. This would probably mean the InstructionProperties class, and then the rust side of Target would replace at least the ._gate_name_map (the Operation objects are still python so this will just contain the raw PyObject), _gate_map, _global_operations, and _qarg_gate_map attributes and then provide similar helper methods to update/append to the target and query the data contained in it. This would let us reuse the same target models in both python and rust space and then remove some of these custom data structures we're using for individual algorithms.

[nkanazawa1989]

Given the direction of future development Qiskit probably we can purge the calibration property from InstructionProperties class in Qiskit2.0? This information is not used unless user wants to convert the entire circuit into a pulse schedule. One of such use cases is the circuit simulation at device Hamiltonian level with Qiskit Dynamics, but today's size of quantum computer is too large to handle with such simulators. I think removal of the calibration property allows you to represent entire Target with Rust object.

Probably, we can revive optional calibration storage like instruction schedule map, but in more efficient fashion (separation of template schedule and parameters as we did in Qiskit Experiments).

[raynelfss]

I'd like to take a look at this, could I be assigned?