Provider refactor — curl-based configuration workflow

[humanizersequel]

Opening this PR now so we can work from the same place if anybody is inclined to take a crack at it tomorrow morning while I'm flying (I cannot into streaming LLM tokens via plane wifi and am therefore basically retarded).

This implements the Provider refactor #69 — I have no idea if it works, because before the actual new mechanism in curl_executor can even be tried it continually fails at the transaction validation step.

See:

Sat 23:04 hypergrid:ware.hypr: ERROR provider::util: provider/src/util.rs:258: Failed to fetch transaction receipt: provider=haiku-api-testing-4, tx_hash=0x79bc8579b8a14a60c92162594708fe4b1ca96648bc575e57c4232c43b9fe21cd, source_node=mewhenimthermometertesting.os, error=RpcTimeout
Sat 23:04 hypergrid:ware.hypr: ERROR provider: provider/src/lib.rs:502: Payment validation failed for provider 'haiku-api-testing-4' from node 'mewhenimthermometertesting.os': Error fetching transaction receipt for 0x79bc8579b8a14a60c92162594708fe4b1ca96648bc575e57c4232c43b9fe21cd: RpcTimeout

That said, actual provider configuration seems to work fine and if my goobercoding has preserved the validation logic (highly suspect it might not have) it at least works on that axis. Screenshot of what the curl-based provider config workflow looks like:

It's not quite as stylish as I'd like it to be but I think it's workable. Obviously needs to be tested e2e.

[humanizersequel]

Note to self for when I revisit this: I never actually got there because of payment validation jank (RPC issues or just need more time for Paymaster tx receipts to get put together?), but obviously the provider I was using to test wouldn't have worked because I published my API key on here earlier and had to zero it out. Lol.

[humanizersequel]

@Gohlub is taking over this PR