Add cast function.

[dnwpark]

Allows users to cast between types:

assert client.get(std.str.cast(std.int64(1))) == "1"
assert client.get(std.array[std.str].cast(
    std.array[std.int64](
        [std.int64(1), std.int64(2), std.int64(3)]
    )
) == ["1", "2", "3"]

Supports scalars, enums, array, tuple, range. Multiranges not supported, not sure we can even construct them in the qb right now.

[msullivan]

Is the idea here that we support generating casts between any two types, and then we let the server deal with figuring out which are real?

That's probably a reasonable first take.
I think eventually we might want to generate overloads based on reflecting the casts in the schema, but this is an expedient first step.

@elprans @1st1 thoughts?

[msullivan]

What happens if you don't do this?
I think it shouldn't matter.

[dnwpark]

Mypy complains about applying the type arguments to std.tuple without this:

tests/test_qb_cast_tuple_01.py:20: error: Bad number of arguments for type alias, expected 0, given 4  [type-arg]

It's ok with std.array though, for some reason...

[msullivan]

Maybe generate these in a separate mtehod?

[elprans]

This is an example of where I feel the explicit cast is inconsistent. We are casting a Python literal string "Red" to std.str via a (Pythonic) call to a constructor, whereas the second cast is via a classmethod.

[elprans]

I feel like this need a bit more work. Ideally we should expose all explicit casts with support for base Python types, e.g the Enum casts should accept Python strings directly without an extra std.str cast.

[dnwpark]

Removing the extra python casts is a more general problem. Will be fixed elsewhere.