Fixup some issue with polyadic arrays.

I have fixed the interpretation of tuples to a big-endian
encoding. This means that the results look like this:

0,0,0 encoding=0
0,0,1 encoding=1
0,0,2 encoding=2
0,0,3 encoding=3
0,0,4 encoding=4
0,1,0 encoding=5
0,1,1 encoding=6
0,1,2 encoding=7
0,1,3 encoding=8
0,1,4 encoding=9
0,2,0 encoding=10
0,2,1 encoding=11
0,2,2 encoding=12
0,2,3 encoding=13
0,2,4 encoding=14
0,3,0 encoding=15
0,3,1 encoding=16
0,3,2 encoding=17
0,3,3 encoding=18
0,3,4 encoding=19
1,0,0 encoding=20
1,0,1 encoding=21

I have modified polyarray_02 test case so it checks
encoding, decoding, and assignment for the tupe 3 * 4 * 5,
it not only prints the results, it also does assertion
checks that encoding and decoding are inverses.

The effect of fixing to big endian encoding is this:
for an array of type T ^ 5 ^ 4 ^ 3 you must index it like
this: where i:3, j:4, k:5, an element is given by

  a . i . j . k

because the first index i selects a submatrix, the second
a vector, and the third an element. This is fixed by how
arrays of arrays must work. With the big endian encoding,
the tuple multi-index is written like this:

  a' . (i,j,k)

to get the same element, where a' is a linearised version
of the array a. In other words the index order is preserved.

Unfortunately the order of dimensions in the type is reversed.
The matrix a' has type

  T ^ (3 * 4 * 5)

There's no way around this. Either the order of the index
types gets reversed, or the order of the indicies gets reversed.

If we reconsider the projections is forward order we get both
being reversed:

  `k (j (i a)

is equivalent to a . i . j . k, and we have

  (i,j,k) a'

as equivalent to

  a' . (i,j,k)

It's the operator . which is reversing the order.

Big endian representations do have the advantage that
total ordering is lexicographical. In particular
comparing (i,j,k) with (i',j',k') lexicographically
from left to right agrees with the ordering obtained
by comparing the integer encoding.

By fixing several parts of the code to now use big endian
encoding I have probably broken other parts, particularly
the type coercions, which previously assumed little endian.
You now have that

  T ^ N ^ M :>> T ^ ( M * N )

with order reversal of the indices. But there's always good news!

If instead of using T ^ N for exponentiation we use the reversed
exponential operator N -> T the order now agrees with curreying:

  M -> N -> T :>> (M * N) -> T

I have made this new choice entirely based on what I felt
comfortable with when reviewing polyarray_02 output.
I wanted the natural indexing order to generate sequential
encodings, and to me the natural interpretation for a tuple
as a variable radix number is big endian because I'm used
to Western (arabic) decimal notation where the biggest digit
comes first. It's illogical! Little endian is actually a better
encoding in general because it's extensible to larger ranges
of values by adding digits on the right. Big endian is not
extensible like this. YMMV. Some choice had to be made.