docs: fix formatting errors in design document (#13648)

## Checklist
- [x] PR author has checked that all the criteria below are met
- The PR description includes an overview of the change
- The PR description articulates the motivation for the change
- The change includes tests OR the PR description describes a testing
strategy
- The PR description notes risks associated with the change, if any
- Newly-added code is easy to change
- The change follows the [library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html)
- The change includes or references documentation updates if necessary
- Backport labels are set (if
[applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting))

## Reviewer Checklist
- [x] Reviewer has checked that all the criteria below are met 
- Title is accurate
- All changes are related to the pull request's stated goal
- Avoids breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes
- Testing strategy adequately addresses listed risks
- Newly-added code is easy to change
- Release note makes sense to a user of the library
- If necessary, author has acknowledged and discussed the performance
implications of this PR as reported in the benchmarks PR comment
- Backport labels are set in a manner that is consistent with the
[release branch maintenance
policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)

Author: emmettbutler

docs/contributing-design.rst

@@ -20,7 +20,7 @@ that is specific to the library being integrated with, and no code related to Pr
 
 The **core** of the library is the abstraction layer that allows Products and Integrations to keep their concerns
 separate. It is implemented in the Python files in the `top level of ddtracepy <https://github.com/DataDog/dd-trace-py/tree/main/ddtrace>`_
-and in the `internal` module. As an implementation detail, the core logic also happens to directly support
+and in the ``internal`` module. As an implementation detail, the core logic also happens to directly support
 `Application Performance Monitoring <https://docs.datadoghq.com/tracing/>`_.
 
 Be mindful and intentional about which of these categories your change fits into, and avoid mixing concerns between
@@ -47,12 +47,12 @@ This is the series of steps involved in autoinstrumentation:
 Step 1: Bootstrap
 -----------------
 
-The autoinstrumentation entrypoint is `import ddtrace.bootstrap.sitecustomize`. This can be done in user code, either directly or via
-`import ddtrace.auto`, or behind the scenes by `ddtrace-run`.
+The autoinstrumentation entrypoint is ``import ddtrace.bootstrap.sitecustomize``. This can be done in user code, either directly or via
+``import ddtrace.auto``, or behind the scenes by ``ddtrace-run``.
 
 ddtrace's sitecustomize script's basic goal is to start the Products that the library implements.
-These are subpackages like `_trace`, `profiling`, `debugging`, `appsec`, et cetera. Before starting these Products,
-some setup has to happen, especially the execution of preexisting PEP648 `sitecustomize` scripts to maintain
+These are subpackages like ``_trace``, ``profiling``, ``debugging``, ``appsec``, et cetera. Before starting these Products,
+some setup has to happen, especially the execution of preexisting PEP648 ``sitecustomize`` scripts to maintain
 user-facing guarantees about the runtime environment in which the application will execute. ddtrace's sitecustomize
 also attempts to "leave no trace" on the runtime environment, especially by unloading all of the modules it has
 used in the course of its setup phases. This helps reduce the possibility that ddtrace will use the same copy of
@@ -63,8 +63,8 @@ Step 2: Start Products
 
 The Products implemented by the library conform to a Product Manager Protocol, which controls common functionality
 like setup, start, and stop. Each enabled Product module is loaded into the Manager instance on import, which happens in
-sitecustomize. In turn, sitecustomize runs the Protocol with `manager.run_protocol()` and later runs additional Product
-setup steps via `preload.post_preload`. Together, these calls comprise the setup of Products that will operate during the
+sitecustomize. In turn, sitecustomize runs the Protocol with ``manager.run_protocol()`` and later runs additional Product
+setup steps via ``preload.post_preload``. Together, these calls comprise the setup of Products that will operate during the
 application's lifetime.
 
 Step 3: Set Up Import Hooks
@@ -73,23 +73,23 @@ Step 3: Set Up Import Hooks
 The core functionality set up during step 2 is autoinstrumentation, which is a prerequisite for many of the other Products.
 
 Autoinstrumentation setup involves registering hooks that will execute when a particular module is imported. The list of
-modules whose imports trigger this registration is defined in `_monkey.py`. During this step, each of these modules has an
+modules whose imports trigger this registration is defined in ``_monkey.py``. During this step, each of these modules has an
 import hook registered for it. In the rest of this document, these modules are called "Instrumented Modules".
 
-Note that as of this writing, autoinstrumentation is implemented as a side effect of the `_trace` Product's setup phase.
+Note that as of this writing, autoinstrumentation is implemented as a side effect of the ``_trace`` Product's setup phase.
 In a more abstract sense, autoinstrumentation can function as its own Product, and in the future may be refactored as such.
 
 Step 4: Import Occurs
 ---------------------
 
 The next step of autoinstrumentation happens when the application imports an Instrumented Module. The import triggers the
-import hook that was registered in step 3. The function that the hook executes has the primary goal of calling the `patch()`
-function of the integration module located at `ddtrace.contrib.<integration-name>.patch`.
+import hook that was registered in step 3. The function that the hook executes has the primary goal of calling the ``patch()``
+function of the integration module located at ``ddtrace.contrib.<integration-name>.patch``.
 
-The goal of an integration's `patch()` function is to invisibly wrap the Instrumented Module with logic that generates the
+The goal of an integration's ``patch()`` function is to invisibly wrap the Instrumented Module with logic that generates the
 data about the module that's necessary for any relevant Products. The most commonly used wrapping approach is based on the
-`wrapt` library, which is included as a vendored dependency in `ddtrace`. Another approach, employed by certain components of the appsec product, involves decompiling the imported module into its abstract syntax tree, modifying it, and then recompiling the module. Inside of the wrappers, it's common for
-integrations to build trees of `core.ExecutionContext` objects that store information about the running application's
+``wrapt`` library, which is included as a vendored dependency in ``ddtrace``. Another approach, employed by certain components of the appsec product, involves decompiling the imported module into its abstract syntax tree, modifying it, and then recompiling the module. Inside of the wrappers, it's common for
+integrations to build trees of ``core.ExecutionContext`` objects that store information about the running application's
 call stack.
 
 Whatever approach is taken, this step only sets up logic that will run later.
@@ -98,7 +98,7 @@ Step 5: Application Logic Runs
 ------------------------------
 
 When the application uses the Instrumented Module after importing it, the wrappers created in step 4 are executed. This causes
-data about the running application to be collected in memory, often as a tree of `ExecutionContext` objects. Any Product
+data about the running application to be collected in memory, often as a tree of ``ExecutionContext`` objects. Any Product
 that was started in step 2 may access these data and use them to build a payload to send to the relevant intake endpoints.
-The classic example is the `_trace` Product, which periodically traverses the context tree for the purpose of creating a `Trace`
+The classic example is the ``_trace`` Product, which periodically traverses the context tree for the purpose of creating a ``Trace``
 object that is subsequently serialized and sent to Datadog to power a flamegraph in the Application Observability product.