Refactor trace and result properties

[msoeken]

This PR cleans up the way properties are handled for traces and results. Trace properties can be assigned by application generators and trace transforms and are stored in optimal resource estimation results. The Python API automatically detects whether the property value is bool, int, float, or str and does not require a dedicated property class exposed from Rust.

Some other changes include

• Fixes a deadlock due to the Python GIL
• Allows parallel trace generation from application generators
• Reorganizes code around Q# application generators
• Sets up resource estimation for memory qubits

[brad-lackey]

This is a bit inconsistant with the general form of set_property/get_property below. It looks like this should be named get_memory_qubits, which is syntactic sugar for composin a conditional based on has_memory_qubits() followed by returning the number.

[msoeken]

It is consistent with all the other getters, like compute_qubits, resource_states, depth. In contrast, get_property is a function because we must pass a property key. In a code example it's as follows:

trace = get_a_trace_from_somewhere()
c = trace.compute_qubits
m = trace.memory_qubits
r = trace.resource_states
name = trace.get_property("name")

What we could do to enhance consistency is returning all properties and then querying them.

name = trace.properties["name"]
has_name = "name" in trace.properties