CodeObject wrapper and global CodeObject registry (#32)

Every event callback receives a _code argument which is of the Python
type CodeObject. We created a CodeObjectWrapper type which wraps this
object for two purposes:

1. To expose an easier to use interface which would focus on what we
need to implement a tracer
2. To minimize performance hit by caching the code object data that we
fetch from the Python object.

A code object corresponds to the body of a function or a module. With
our wrapper and registry we guarantee that each code object is processed
at most once.

Author: tzanko-matev

.agents/tasks/2025/08/21-0939-codetype-interface

@@ -0,0 +1,42 @@
+Implement an interface for the CodeType object.
+
+The Python Monitoring API passes a CodeObject to each event handler. In the current implemenation of our Tracer trait the event handlers have an argument `_code: &Bound<'_, PyAny>` which gives
+access to this object. This is not a good interface because the type is too generic. PyO3 has a PyCodeObject type, however it doesn't expose any public members because the type is unstable,
+so we cannot use that one.
+
+We need to create our own type CodeObjectWrapper which can simplify access to the underlying code object type. Then we should use this type in the signature of the methods in the Tracer trait.
+The type should allow easy access to that functionality of the underlying code object which we will need to implement a recorder for a time-travel debugger. 
+On the other hand it is important not to introduce any performance problems. Some ideas to think about:
+- Minimize the copying of values
+- Repeated computations on each event call could be memoized
+- Any other approach that minimizes the performance hit
+
+Propose a design of the CodeObjectWrapper type. Write the design in design-docs/code-object.md. Do not actually implement the type for now, I need to confirm the design first.
+
+Here's relevant information:
+* design-docs/design-001.md - shows how we write design documentation
+* https://docs.python.org/3/library/sys.monitoring.html - Documentation of the Python sys.montoring API
+* https://docs.python.org/3/reference/datamodel.html#code-objects - Description of Python Code Objects.
+
+--- FOLLOW UP TASK ---
+Please address any inline comments on the diff, as well as any additional instructions below.
+
+According to the PyO3 documentation it is preferred to use  instead of Py<T>. Is it possible that the code object wrapper takes that into account? Here is relevant info:
+* https://pyo3.rs/v0.25.1/types.html
+* https://docs.rs/pyo3/0.25.1/pyo3/index.html
+
+Also please add usage examples to the design documentation
+--- FOLLOW UP TASK ---
+Please address any inline comments on the diff, as well as any additional instructions below.
+
+According to the PyO3 documentation it is preferred to use `Bound<'_, T>` instead of Py<T>. Is it possible that the code object wrapper takes that into account? Here is relevant info:
+* https://pyo3.rs/v0.25.1/types.html
+* https://docs.rs/pyo3/0.25.1/pyo3/index.html
+
+Also please add usage examples to the design documentation
+--- FOLLOW UP TASK ---
+Implement the CodeObjectWrapper as designed. Update the Tracer trait as well as the callback_xxx functions accordingly. Write a comprehensive unit tests for CodeObjectWrapper.
+--- FOLLOW UP TASK ---
+There is an issue in the current implementation. We don't use caching effectively, since we create a new CodeObjectWrapper at each callback_xxx call. We need a global cache, probably keyed by the code object id. Propose design changes and update the design documents. Don't implement the changes themselves before I approve them.
+--- FOLLOW UP TASK ---
+Implement the global code object registry.

codetracer-python-recorder/Cargo.lock

@@ -18,6 +18,8 @@ default = ["extension-module"]
 pyo3 = { version = "0.25.1" }
 runtime_tracing = "0.14.0"
 bitflags = "2.4"
+once_cell = "1.19"
+dashmap = "5.5"
 
 [dev-dependencies]
 pyo3 = { version = "0.25.1", features = ["auto-initialize"] }