"Properly" update epslevels after scalar-chebtech multiplcation.

This closes #1201.  The improper update to epslevel in chebtech.times() in
particular was causing rather strange results:

>> f = 1e16.*chebtech2(@(x) x)
f =
  2x1 chebtech2 array with properties:

      coeffs: [2x1 double]
      vscale: 1.000000000000000e+16
      hscale: 1
     ishappy: 1
    epslevel: 2.000000000000001

As a preemptive measure, I've gone ahead and changed several other places where
we were updating epslevel in this context based on our heuristic rules to use
updateEpslevel() instead as well.  There are also a few changes some things
having to do with how epslevel gets updated when a function with a zero vscale
is encountered to avoid NaNs.

I make no claim that these are the right things to do in these situations, only
that they are "reasonable".
Use "proper" epslevel bound in chebtech.plus().

This partially addresses #1206.  Before this commit, if we made a chebtech2
like

>> f = chebtech2(@(x) sin(1e4*x))
f =
  10204x1 chebtech2 array with properties:
      coeffs: [10204x1 double]
      vscale: 0.999999988857274
      hscale: 1
     ishappy: 1
    epslevel: 2.220383606032091e-12

and added zero to it, the epslevel would miraculously improve to 2.22e-16:

>> f + 0
ans =
  10204x1 chebtech2 array with properties:
      coeffs: [10204x1 double]
      vscale: 0.999999999770504
      hscale: 1
     ishappy: 1
    epslevel: 2.220446049250313e-16

The reason this happens is that in updateEpslevel, if the epslevelBound
argument is not supplied, it defaults to chebtech.techPref().eps, which is
2.22e-16.  This gets used as an upper bound when determining the final
epslevel, which is too optimistic.  With these changes, we supply a "proper"
bound using Hale's Heuristics (see documentation in @chebtech/chebtech.m), and
the epslevel is unchanged:

>> f + 0
ans =
  10204x1 chebtech2 array with properties:

      coeffs: [10204x1 double]
      vscale: 0.999999999770504
      hscale: 1
     ishappy: 1
    epslevel: 2.220383581800533e-12
Add a heuristic "bound" for updating the epslevel in cumsum().

Here's the "justification" for this:

Say f is the true function we want to approximate and p is the chebtech we end
up using to approximate it.  We sort of hope that we have something like

  ||f - p||/||f|| <= eps(p),

where eps(p) is the epslevel of p and ||.|| is the infinity norm.  If Ix is the
operator which integrates from -1 to x and I is the operator which integrates
from -1 to 1, we have

  |Ix(f) - Ix(p)| <= Ix(|f - p|)
                  <= I(|f - p|)
                  <= eps(p)*||f||*I(1)
                   = 2*eps(p)*||f||

If we replace ||f|| with the vscale of p and assume the vscale of Ix(f) is
reasonably well-approximated by the vscale of Ix(p), this suggests the "bound"

  eps(Ix(p)) <= 2*eps(p)*vscale(p) / vscale(Ix(p)).

No, this isn't rigorous, but then again, nothing epslevel-related is anyway.
At any rate, this at least should prevent epslevel explosion while still
allowing us to avoid the odd behavior pointed out in #1206.

To prevent problems similar to those from #1206 from arising in the future, I
want to change the default upper bounds in updateEpslevel() to Inf instead of
pref.eps, but I don't have a good understanding of how this will affect things.
Prior to this commit, making such a change resulted in problems with taking the
indefinite integral of, e.g., degree-2 polynomials, which have no tail, causing
the happinessCheck() in updateEpslevel() to return a new epslevel which is
complete nonsense.  After making this commit, it seems to be safe to do, but
I've decided instead to just leave TODOs there for now.

One tolerance on a tests in tests/bndfun/test_cumsum.m needed to be increased
slightly as a result of these changes.
"Handle" NaN chebtechs in chebtech.updateEpslevel().

tests/singfun/test_isnan.m does NaN*f in one place, and updateEpslevel() chokes
when it tries to compute the epslevel of the result because the NaN
coefficients cause classicCheck() to crash.  There are several possible ways to
handle this.  This commit does it by temporarily replacing the NaNs with zeros
to prevent classicCheck from crashing and then leaving the epslevels of NaN
columns unchanged at the end of the procedure.

I don't claim that this is the "correct" solution, since the whole "NaN
chebtech" concept has not been thought through anyway, but it should do for the
time being.
Merge pull request #1213 from chebfun/fix-epslevel

fix-epslevel