Cleaning up @deftypefn classes in documentation

[Rik]

7/10/13

John,

In intro.txi we outline the different possible values for the first field
of the @deftypefn macro.  They are:

Function File
Built-in Function
Loadable Function
Mapping Function
Command
Built-in Variable

First, "Built-in Variable", hasn't really been a valid class for 6 years
now.  I think that should just be deleted as well section 1.3.5.3 of the
manual which describes it.

Second, the other classes aren't quite orthogonal so it leads to difficulty
in categorization.  Any function can be called in both a function form or
command form for example.  The function may not work in command form if it
is not expecting string input, but it can still be called that way.  So
Command is not quite distinct from any of the Function entries.  Also, the
Mapping function is not distinct either since mappers can be both built-in,
like sin, and from function files as in sind.

What about aligning the descriptions based on source?  This mostly
parallels the existing structure and usefully indicates where to go to find
out more about a function.  It also gives an idea of whether there is room
for improvement; A Built-in Function is written in a compiled language and
going to be awfully fast already.  Under the new scheme there would be the
following categories:

M-file Function
Built-in Function
Loadable Function
M-file Command
Built-in Command
Loadable Command

The Command form would be used only when the function works for all
different input combinations in the command form.  If there is a single
situation where it doesn't then the Function keyword would be used.

--Rik