Nargin, nargout validation after interpreter changes

@jwe made a change to the interpreter so that it now checks that the number of inputs and outputs when calling a function do not exceed the number specificed in the function signature.

This left a lot of redundant code that could be eliminated. The form of the m-file would look something like this:

function [out1, out2] myfunc (required_in1, in2)

  if (nargin < 1 || nargin > 2 || nargout > 2)
    print_usage ();


Assuming the first input was required and the second optional this can now be shortened to

  if (nargin < 1)
    print_usage ();

I used some Perl, as well as a lot of manual labor, to clean up the core. See The same thing should be done for all of the packages before the 7.1 release as well. I can share my Perl script if anyone is keen, or the package maintainers can just go through their functions.

More chores that should be done on the code base. There are now a lot of redundant %!error BIST tests that were checking the input validation code. Those tests that were just verifying number of inputs and outputs should be deleted, and a test of the interpreter made in test/func.tst.

It’s a small thing, but I think we should consider swallowing one level of the backtrace when we hit an input validation error. I used this test code in a file tst_func.m.

function [out1] = tst_func (in1, in2)

  # Call tst_func2 incorrectly to check backtrace
  x = tst_func2 ();


function tst_func2 (in1)

When I call it in various ways I get

octave:1> [x,y]  = tst_func
error: tst_func: function called with too many outputs
error: called from

octave:3> tst_func
error: tst_func2: function called with too many outputs
error: called from
    tst_func at line 4 column 5

I don’t think the backtrace level with no line number is useful. The point where code modifications would have to happen is always one stack level higher as in the second example. Do others agree?

It was simple enough so I added the BIST test for the interpreter in test/func.tst in this changeset:

It might still be useful to have a hint which (potentially shadowed) function Octave tried to call.
So imho, the stack trace should contain all the information that is does now. Though a line number might be useful (but not strictly necessary) to get the hint.