Make .optArgs(...) nicer

[NotJustAnna]

This issue is a continuation of rethinkdb/rethinkdb#5184

From the original issue:

Currently we just have a two argument chainable method for optargs:

between(3, 100).optArg("left_bound", "open").optArg("right_bound", "closed")

But we actually can do better than this since we have all of the optarg names and types listed in global_info.json, I believe it would be possible to do something along the lines of:

between(3, 100, Optarg.of<>()
    .leftBound(Bound.OPEN)
    .rightBound(Bound.CLOSED))

Pros:

1. Optargs can be checked at compile time

2. Syntax is a bit better than chaining `.optArg` a bunch of times

3. Better syntax for lambdas provided to optargs.

[...] I think in general the java community is in favor of stronger typing and this is a place I think it's tractable to provide stronger typing. The number of optargs is enumerable and they don't (currently) allow a reql term to dynamically evaluate their value

[...]

Another developer's reply:

The contra argument for doing this is that we will need to maintain the list of supported optargs in the future.

I have a slight preference for keepings the optarg syntax the same it is now, and not introducing specific methods for the different optional arguments.

It seems that optArgs functions are implemented in v2.4.0.

I'm neutral on this issue, and encourage discussing regarding whether this is feasable and doable or not.

This issue also relates to #11 because it would need modifying the python scripts.