Deprecate tuple decoders

[mlms13]

tupleFromFields should definitely go... there have been times I wanted that in the past, and even I didn't remember it exists. With the addition of let-ops, that one is way more easily expressed as:

let+ first = field("first", string)
and+ second = field("second", boolean);
(first, second);

And while thinking about that, I started to wonder if the helpers like tuple2 and tuple3 could also be simplified. I'm thinking something like:

let+ first = arrayAt(0, string)
and+ second = arrayAt(1, boolean)
and+ third = arrayAt(2, date);
(first, second, third);

The downside is that it's more verbose than what we currently have, but I see several upsides:

• the syntax is consistent with decoding objects/records, so there are fewer concepts to remember
• you aren't arbitrarily capped at a 5-tuple... tuples can get as big as you want
• picking specific positions out of arrays might be generally useful even outside of tuples

JSON-encoded tuples aren't a supper common occurrence in my experience, and the current approach requires quite a bit of code to support. I'll have to think about it, and I'm happy to hear any feedback.

The Plan:

• [x] add arrayAt
• [x] deprecate tupleN
• [x] deprecate tupleAtLeastN

And when these are actually removed in 2.0, I'll make sure to add tuple examples to the docs and also include this change in an upgrade guide.

[mlms13]

This would be consistent with the goal to remove mapN functions (see: #123).

I was previously on the fence, but I think I've decided that the increased flexibility and the fewer concepts for library users to learn makes this change worth it, even if the resulting user code is just a little more verbose.