Add new_context to instrumentation

[njz-cvm]

As per #1493, it's current a bit awkward to remove context from instrumentation. This PR adds the "new_context" keyword to ensure designated function calls do not inherit from parent spans.

Here is an example from the new test:

def context_factory():
    return {'new_contex': 123}

@tagged.instrument('hello-world {a=}', record_return=True, new_context=context_factory)
def hello_world(a: int) -> str:
    return f'hello {a}'

@tagged.instrument('parent', record_return=True)
def parent() -> str:
    return hello_world(5)

Alternatively, new_context can be set to True, which is the same as new_context=dict.

[codecov]

Codecov Report

❌ Patch coverage is 94.11765% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
logfire/_internal/instrument.py	91.66%	2 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[alexmojaki]

We didn't discuss this context factory API, I'm not sure if I like it or understand the point. It's certainly not being tested here, new_contex doesn't do anything or appear in the exported spans.

[njz-cvm]

I didn't mention it in the original issue because it wasn't something I'd considered. But when I realized I'd just be using attach_context behind the scenes, it seemed preferable to allow users the option to provide input for attach_context.

If you're against it, it's not that useful for me and I don't mind cutting it. But if it's worth keeping I'll add better testing for it.

[alexmojaki]

this feature isn't really compelling enough without the span link

[njz-cvm]

this feature isn't really compelling enough without the span link

I'll look at adding it, just trying to determine the best approach.