fix(langchain): non-dict inputs in LCEL chains

[Towerthousand]

When using a multi-step LCEL chain with dd-trace active, the langchain patch runs traced_lcel_runnable_sequence (and its async version) to instrument the call. This function tries to set a tag for every input, as seen in this code bit:

        try:
            inputs = get_argument_value(args, kwargs, 0, "input")
        except ArgumentError:
            inputs = get_argument_value(args, kwargs, 0, "inputs")
        if integration.is_pc_sampled_span(span):
            if not isinstance(inputs, list):
                inputs = [inputs]
            for idx, inp in enumerate(inputs):
                if not isinstance(inp, dict):
                    span.set_tag_str("langchain.request.inputs.%d" % idx, integration.trunc(str(inp)))
                else:
                    for k, v in inp.items():
                        span.set_tag_str("langchain.request.inputs.%d.%s" % (idx, k), integration.trunc(str(v)))

The problem is that input might be a single, non-dict-like object. This happens, for example, when using langchain's Pydantic parser as the output to a chain step and pipe it into a further PromptTemplate. We've reproduced this with the create_structured_output_runnable call, but should happen with any chain that has a dict input. Throws an error when trying to access inp.items().

Checklist

• [X] The PR description includes an overview of the change
• [X] The PR description articulates the motivation for the change
• [X] The change includes tests OR the PR description describes a testing strategy
• [X] The PR description notes risks associated with the change, if any
• [X] Newly-added code is easy to change
• [X] The change follows the library release note guidelines
• [X] The change includes or references documentation updates if necessary
• [x] Backport labels are set (if applicable)

Reviewer Checklist

• [ ] Title is accurate
• [ ] All changes are related to the pull request's stated goal
• [ ] Avoids breaking API 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