Add flexibility to parsing "Reasoning" info to account for LLMs that struggle to format data correctly - example with codellama34b

[jwmatthews]

I ran an example with codellama34b running with a local ollama setup and wasn't able to see the Reasoning info displayed

We were not able to display the "Reasoning" info the LLM returned as the LLM returned the info as:

    # Reasoning
    The first step in migrating this code from Java EE to Quarkus is to replace the `@MessageDriven` annotation with a CDI scope annotation like `@ApplicationScoped`. This is because Enterprise Java Beans (EJBs) are not supported in Quarkus, and CDI must be used instead.

instead of

    ## Reasoning
    The first step in migrating this code from Java EE to Quarkus is to replace the `@MessageDriven` annotation with a CDI scope annotation like `@ApplicationScoped`. This is because Enterprise Java Beans (EJBs) are not supported in Quarkus, and CDI must be used instead.

Trace info here from the response of the LLM
https://gist.github.com/jwmatthews/2df46a61d5cc2252d7a49bf8a1768da6

I'm suggesting we consider either:

• look at the prompt side to get clearer instructions to help nudge the LLM to enforce the output schema we require (for new contributors curious to see how we construct the prompt you can look here kai/reactive_codeplanner/agent/analyzer_fix/agent.py
• or see if we can relax our parsing rules to handle a bit of flexibility with LLMs that may struggle to honor our formatting requests.

[jwmatthews]

Related to #475

[jwmatthews]

I see this with ollama and granite 8b code instruct as well