List.end Considered Harmful

All the .pairs-like list methods calculated .keys first, then looked
up everything using at_pos.  Unfortunately, to determine the key list,
the .keys method called self.end, which enforces finite semantics.  This
seems a bit suboptimal in a language that professes to support infinite
lists.  So now instead of mapping the keys, we map the values, and create
the keys as needed.  Performance seems roughly the same.
combinations didn't itemize when k == 0

The null set was omitted from the powerset.
[1,2] Xop <a b> now treats [] as item
define X in terms of X,
define Z in terms of Z,
list infix reductions no longer flatten

Since we fixed X and Z metaops to not violate Scalar containers,
we have to be able to pass a list of parcels to [Xop] and [Zop]
and have each parcel treated as a separate list.  The triangle
forms also work (slowly, since they have to recalculate each stage
from the start), but there is an unbox warning I don't understand yet.
hand revert def of X/Z in terms of X,/Z,
Xop and Zop could clobber input array
do the Don't Flatten Scalars jig for bare X and Z
simplify using nqp::iscont as suggested by jnthn++
ensure 1st arg to X is lazy
add deepmap, make unary hypers shallow as specced
fix botched laziness patch on X
further detangling of deepmap from hyper
better fix for lazy X
Merge branch 'nom' of github.com:rakudo/rakudo into eleven
speed up Xop by more than 2x

'X,' is now only slightly slower than 'X'
optimize 'X,' to 'X'
add duckmap, more nodality infrastructure
handle hyper subscripts (1 arg only so far)