Add current_span option to nocode instrumentation

[johnbley]

Add a new current_span: true option to nocode rules, allowing you to add attributes to the currently active span by adding runtime instrumentation to a method as before. This makes it easier to support usage like capturing a cookie value on a root servlet span, without needing to create a child span just to have the cookie value.

• span_name and span_status have no effect (besides logging a parse-time warning about this) on current-span rules
• if no span is active/current at runtime, nothing happens
• adding both span-creating/"regular"and current-span rules to a single method is supported and the order in the yaml config is the order they are evaluated at runtime

This PR was created by codex 5.4 extra-high from my spec (listed in comment for completeness), with some light tweaking/tuning/commenting by me.

[johnbley]

codex spec with many human typos, for reference:

Take a look at the nocode instrumentation in this repository.  Currently each nocode rule adds instrumentation that creates a new span in the instrumented method, and allows various otel bits to be set (span name, status, adding attributes).  I would like there to be an optional way to add attributes to an existing (current/active) span by instrumenting a method and just adding the attribtues to whatever the active otel span is.  I have started this process by adding `Rule.isCurrentSpan` but it currently default to false.  
I would ilke a `current_span: true` option on the nocode rule at the yaml level, implicitly/default false so older rules do not have to be touched.  current-span rules should have their span name and status ignored, with a logged warning about that not being supported.  At runtime, if no span is active, the instrumentation should silently do nothing.
As part of this work, please check (end modify code to ensure, if necessary) that rules are applied in the order specified in the yaml file, such that a method instrumented with both "regular" and "current-span" rules will have predictable behavior.
Do not modify any existing unit tets except for basic compilation requirements.  Add unit tests for the new functioanlity, including at least one "no action taken when no span is active" test.
Refactor out code as necessary to share logic between regular and current-span rules, but do not introduce new interfaces or helper classes without checking with me first, as the rules around classloaders are complicated for -javaagent instrumentations.
Do you have any requirements questions before beginning?

A first draft of this went off the rails as codex couldn't figure out how to rerun the necessary build steps when editing bootstrap code, so I helped it along by doing that manually.