Add Context API

[fedimser]

• This PR introduces a new concept - Context, which is a wrapper around what currently was a global state - Interpreter instance, Config instance and code namespace with defined Q# symbols.
• Most public module-level methods (e.g. qdk.eval, qdk.run) have been migrated to Context. The module-level methods call methods with the same name on default global context.
• qdk.init now creates a new Context (passing init arguments to constructor) and stores it in global _default_context variable.
• interpreter.get_default_context() now can be used to access global context and lazily initialize it if needed. However, it's not public API.
• Also, added method Context.import_openqasm which is migrated from qsharp.openqasm.import_openqasm.
• Two deprecated methods, estimate and dump_circuit were not migrated. Instead, their implementation is kept in place, but it refers to global context.
• There are multiple places using global interpreter. For them to keep working, added 3 functions get_interpreter, python_args_to_interpreter_args, qsharp_value_to_python_value that access interpreter and converters from the global context.
• Fixed a bug where circular check in Python-Q# object conversion was not happening, because set.add returns None here.
• Code for conversion from Python to Q# now has to be in context of a Context (because it needs to forbid cross-context object passing), so I moved it to be methods of Context. class.
• This PR is based onhttps://github.com/Introduce QdkContext API for isolated interpreter sessions #3029 with some changes. In particular, added isolation checks (that callables and structs from one context cannot be passed to another).
• This PR addresses The QDK Python layer should have knowledge of its initialization state #2998

Example

import qdk

ctx = qdk.Context()
ctx.eval("operation Main() : Result { use q = Qubit(); X(q); MResetZ(q) }")
assert ctx.run("Main()", 2) == [qdk.Result.One, qdk.Result.One]
assert ctx.code.Main() == qdk.Result.One

Recommended usage

• For notebooks and small projects, module-level API (qsharp.init, qsharp.eval, qsharp.code) is okay to use and we will not deprecate it.
• It is also okay to use Context anywhere you want, but there should be no need to use 2 contexts in the same notebook.
• For writing Python libraries which wrap around Q# code, you must use a single Context per library to make sure you have isolated interpreter and its state is not changed by any other libraries or user code that might exist in the same Python context.
• 2 styles (global vs Context) should not be mixed. In particular, we do not expose a method to get access to global Context. If you want to use Context, it must be created with constructor.

API changes

• Added a single new exported symbol - a class qsharp.Context with 9 public methods: eval, run, compile, circuit, logical_couints, set_quantum_seed, set_classical_seed, dump_machine, import_openqasm.
• Each context also has dynamic namespace code which contains all defined Q# symbols, which can be used like qsharp.code was used before.
• All existing method-level APIs (including deprecated estimate and dump_circuit) are there and have exactly the same observed behaviur. qsharp.init internally creates new global context and returns config assosiated with that context.
• While we added function get_default_context() which accesses default global context (with lazy initialization), it is intended only for usage within the library, and is not exported as public API.

Documentation

• Now have 9 methods (function in qsharp module vs method in Context class), plus qsharp.init vs Context.__init__, which do basically the same and take the same arguments. Because none of them is deprecated, and both are public API, both needs to be documented. Therefore, I had to duplicate exactly lengthy pydocs and argument descriptions, and they will have to be kept in sync in the future.