Adding several gallery* examples.

gallery:
   + chebdermonde, random, vandermonde
   + relevant tests

gallerytrig:
   + noisyfun, random, starburst
   + relevant tests
Resolving merge conflict.

The conflict was caused by the fact that I was working with an
old version of +cheb, one from before Daubechies was added.
making sure that chebfun(f) has the same domain as f, if f is a chebfun.
making sure tests pass.
fixing warning for trig based chebfuns.
Changes agreed upon in the meeting.

+ "chebdermonde" -> "vandercheb"
+ gallery* with no output argument creates a plot of the function
  with appropriate title and axis limits
+ removing () syntax notation in the documentation
Adding sinefun1 and sinefun2 to gallerytrig

+ also adding length/rank to title of plots
Renaming vandercheb in documentation.
Merge remote-tracking branch 'origin/development' into fix-chebfun-domain
Modify commit + coding style.
am->AM and fm->FM.
Merge branch 'development' of ssh://github.com/chebfun/chebfun into feature-gallery-things
Minor documentation fixes.
adding a test for constructor.
Merge branch 'fix-chebfun-domain' of https://github.com/chebfun/chebfun into fix-chebfun-domain
Merge remote-tracking branch 'origin/development' into fix-chebfun-domain
Merge pull request #1320 from chebfun/fix-chebfun-domain

Fix chebfun domain
Error out if given a keyword preference with no corresponding value.

Note that this only works for preferences which are lumped into
keywordPrefs and not those which are parsed separately.  Doing this for
the latter as well would probably double the length of the input parsing
routine with the way we're doing things currently.  To fix this, we
could rewrite the code for the preferences which are parsed separately
to use keywordPrefs.

That said, this is probably more complicated than it seems.  For one,
there are options like "trunc", which get handled in a different way
still, and for another, we sometimes need to do parsing on the value as
in "splitting" and "chebkind".  The way keywordPrefs works does not
allow for that at present, and it would not be advisable to make
substantial changes to the input parser so close to a release.

This is meant to address one of the points brought up in #1296.
Have (chebtech|trigtech).techPref() issue warnings for unknown preferences.

This commit is meant to address #1296.

There are two reasons this must be done inside chebtech and trigtech and
not inside chebfun.parseInputs().  First, and most importantly, techs
are the only objects which know enough to be able to validate their
preferences.  In this case, the validation is a simple check of struct
fieldnames and could easily be handled by chebfun by doing
pref.tech().techPref() at the appropriate part in the parsing routine
and comparing the fields to those in pref.techPrefs; however, one could
easily imagine a tech with a set of preferences which requires a more
complicated validation procedure, e.g., the preferences could have
nested structs, and it might be desired to do validation on the contents
of the substructs as well.

The disadvantage to doing this check at the bottom inside the individual
techs is that the overhead added could be greater than if we did a check
at the top in chebfun.parseInputs().  My current belief is that the
impact of this is likely to be minimal since this check is not done very
often (once per every tech constructed using its constructor when the
constructor is explicitly supplied a preference object), but we'll see.
Comparing the two strategies using a profiler run on chebtest('chebfun')
seems to indicate that running the check at the top has less overhead
but not by a whole lot, and there is no discernible difference between
the total time taken for their respective runs.

If the overhead turns out to be too great, an alternative might be to
create functions trigtech.validatePrefs() chebtech.validatePrefs() which
chebfun can call inside of chebfun.parseInputs() via something like
pref.tech().validatePrefs(inputPref).  The disadvantage to this is that
it won't work if funqui is used, but maybe that doesn't matter.

(Personally, I think that whether or not funqui is employed should be an
independent preference, i.e., it shouldn't piggyback on top of the tech
selection mechanism.  That would solve this problem, but this is a
discussion for another day.)
Fix some misspelled preference names.

Only two items to note here:

1.  The fact that we weren't aware of this until now means that the
impact these preference has on things seems to be unimportant.  Do we
really need to be setting them here?  If so, we should find some
examples demonstrating that and add them to the tests.

2.  chebfun really should not be messing with the refinementFunction
preference (or, equivalently, the "resampling" input to the
constructor).  The reason is that this is a preference that only makes
sense for chebtech/trigtech and may not apply to arbitrary techs (and
even if it does, it may not have the same meaning).  In most of the
cases where it's being used, it's setting it to use nested refinement,
which is already the default anyway.  In the one case where it sets it
to use non-nested refinement (@chebfun/inv.m), it has no bearing on the
outcome of the test, so perhaps we simply don't need to set it (as in
point #1, above).