merge of 64-bit changes

[John W. Eaton]

I've merged all of the 64-bit changes you sent except for the
following:

  * changes to odessa, which is no longer a part of Octave

  * changes to pt-plot.{h,cc} which is no longer a part of Octave

  * changes involving #pragma or explicit parallelization -- what to
    do about this is a separate issue from the 64-bit changes for
    large arrays, and can be dealt with later

  * changes related to your extract_keyword64 function, which does not
    apply now -- we need another way to solve this problem, probably
    by converting the extract_keyword{,s} functions to be template
    functions.

I've also made a lot of int -> octave_idx_type changes for the sparse
code, but it is not complete.  There will likely be some problems
interfacing with UMFPACK and COLAMD, since those seem to use "int" for
nr, nc, nnz, etc.

We will have some problems with all the binary data files formats
since they use fixed sizes to store dimension information and now we
need to store 8-byte integers instead of 4-byte integers for those
values.

All these changes are checked in on the CVS branch that is tagged
"branch-64-bit-merge".

To see the complete diffs on that branch since it was split from the
main CVS trunk, check out a copy of the branch and make a diff back to
the branch point:

 cvs -d :ext:address@hidden:/cvs checkout -r branch-64-bit-merge octave
 cd octave
 cvs diff -u -r before-64-bit-merge

Octave continues to build and work as always unless you use

  configure --enable-64

explicitly to tell the configure script to check to see if pointers
are 8 bytes wide and then try to find an 8-byte integer type to use
for indexing.  Otherwise, it defaults to "int" for octave_idx_type,
same as before.

If you do use --enable-64, you will need to set options for the
Fortran compiler so that it will use 8-byte integers.

These changes are likely to cause trouble for any external libraries
(ATLAS, FFTW, HDF5, MPI, etc.) unless they are written to use an
8-byte type for dimensioning and indexing arrays.

Suggestions for automated ways to solve these problems are welcome.

I would like to merge these changes with the main CVS trunk as soon as
possible, because if we wait, there will be more conflicts to resolve
as the two CVS branches diverge.  Are there any objections to doing
that?

jwe