Provider Configuration needs non-string variable support

[humanizersequel]

The provider should be able to handle nonstandard or nested input types in a POST+JSON request.

Context is that I was trying to directly add the Anthropic API as a provider. The curl for that api looks like this:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $apikeyhere" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-3-5-haiku-20241022",
    "max_tokens": 1024,
    "messages": [
        {"role": "user", "content": "Please write a poem about songbirds"}
    ]
}'

When you go to fill this out the in the provider interface, you get to something that looks like this:

The showstopping issue is that the Provider client forces the body keys to confirm to the "string": "string" format. However, the Anthropic API expects "string": [array]" (an array of message objects like {"role": "user", "content": "Please write a poem about songbirds"}, {"role": "assistant", "content": "stop writing poetry and get back to work"}, etc, although the particulars don't matter here.

I should be able to define the expected variable type in more detail. Sidebar: the process of uncovering this behavior this I tested out #59 and it was pretty helpful.

UNCLEAR: would this require changes to the way that the shim + operator parses tool calls? I would think we can sort it out on the Provider side (ie Operator sends over value "["messages", "[{"role": "user", "content": "Please write a poem about songbirds"}]" and knows to strip the other quotes and not parse it as a string in the final HTTP request) but maybe that's less elegant.