more compatibility changes

[John W. Eaton]

In addition the recent changes I've made to replace variables like
do_fortran_indexing, prefer_column_vectors, implicit_num_to_str_ok,
implicit_str_to_num_ok, ok_to_lose_imaginary_part with other variables
that only control whether warnings are printed, I've just checked in
some more similar changes for

  empty_list_elements_ok  -->  warn_empty_list_elements
  resize_on_range_error   -->  warn_resize_on_range_error
  treat_neg_dim_as_zero   -->  warn_neg_dim_as_zero

I'm also considering the following changes:

  * Remove the built-in variables initialize_global_variables and
    default_global_variable_value and only implement the Matlab-like
    thing of always initializing global variables to [], or make the
    default values Matlab compatible.

  * Remove the built-in variable default_eval_print_flag and only
    implement Matlab-compatible behavior, or make the default value
    Matlab compatible.

  * Remove the built-in variable whitespace_in_literal_matrix and only
    implement Matlab-compatible behavior, or make the default value
    "traditional" for Matlab compatibility.

    I don't think that eliminating whitespace_in_literal_matrix would
    cause trouble for code distributed with Octave since it should
    already work with any setting of this variable.  Also, we already
    have a warn_separator_insert to allow warnings to be printed in
    cases like [eye (n)], but it should probably be improved to only
    warn about cases that are potenially troublesome (like the example
    above) and not things like [1 2].

My current preference would be to remove these variables entirely
rather thanjust changing the default values so that we no longer have
to worry about trying to make code work for different settings.

Comments?

jwe