Allow both camelCase and snake_case arguments

### What was wrong?

We've switched the whole code base over to utilize snake_case now. However, we opted to keep some of the keyword arguments, and dictionary keys (specifically transaction and filter params) that get passed directly to the JSON-RPC endpoints as camelCase. We thought it would be more confusing if an error came back from the node provider with a camelCase param when a snake_case param got passed in. But, it's confusing and unintuitive that there are still some residual camelCase params sticking around. It would be most convenient if we could accept both.

### How can it be fixed?

Explore how difficult it might be to accept both snake_case and camelCase params. This might be in the form of new middleware or adding to the existing pythonic middleware or possibly something else.