Add standard "Program Files" location on Windows to find chrome.exe and firefox.exe

Use EvalFast instead of Eval. This changes have been commited in the  master before and they were lost as part of the rebase

Grabbing the number of threads available to the pool through ImplicitMT as npartitions instead of numCPUs in the system.

Changed arrays to vectors and fixed some other bugs to get parallelization to match results of non parallelized version.

Parallelized sum in node and boosting via update predictions loop in MethodBDT and various loops in LossFunctions.cxx

The minimizer test quite often did not converge. As a result there were
many spurious test failures.

The test is tuned to converge _much_ more reliably by increasing the
learning rate (0.0001 -> 0.001), and the number of early stopping epochs
(5 -> 50).

This commit also makes the `testMinimization` test the minimizer
_without_ using momentum (this code path was previously untested here).

The following code was used to benchmark changes (only single precision
part of the test was tested and some aux text was commented out if you
want to reproduce):
```
for i in `seq 100`; do tmva/tmva/test/DNN/testMinimizationCpu; done | awk '{print $6;}' | python -c 'import numpy; import fileinput; a = map(float, fileinput.input()); print(numpy.std(a), numpy.mean(a), numpy.min(a), numpy.max(a))'
```

Results (typical values):
 - Old version: 2.70*10^{-7} (std dev), 3.34*10^5 (mean), 2.27*10^{-6} (min), 0.0017 (max)
 - New verstion: 2.59 * 10^{-6} (std dev), 2.51*10*{-6} (mean), 1.16*10*{-7} (min), 1.37*10^{-5} (max)

Time taken is roughly doubled (~1 sec -> ~2 secs).

All results on local mac.

this includes:
- Data Sources
- Utilities
- Tests

Using -ffast-math is causing linking problems like the one below in the
nightly builds with Clang 7 + GCC 6.2:

CMakeFiles/VecOps.dir/src/TVec.cxx.o: In function `exp':
 /.../include/c++/6.2.0/cmath:246: undefined reference to `__expf_finite'

This is because when linking with -ffast-math, the compiler is expecting
the symbol __expf_finite to be in libm.so, but it is not there:

$ nm -D /lib/libm-2.12.so | grep expf
00012010 W cexpf
00010aa0 W expf
000141d0 W frexpf
00014240 W ldexpf

The vectorized math functions were only introduced in glibc-2.22, so
on a machine with a more recent glibc, however, the symbols are there:

$ nm -D /lib/libm-2.26.so | grep expf
000000000004d5d0 W cexpf
000000000006bbe0 W cexpf128
000000000000f930 W expf
000000000006fb10 W expf128
0000000000050f20 T __expf128_finite
0000000000040de0 T __expf_finite
00000000000489b0 W frexpf
0000000000064080 W frexpf128
0000000000048a60 W ldexpf
00000000000641b0 W ldexpf128

More information: https://sourceware.org/glibc/wiki/libmvec

We would like to use, e.g. decltype(std::sin(std::declval<T>())) to get
the right return type, but the resulting mangled name creates ABI issues
with certain compilers. Since the rules are straightforward at least for
the math functions we intend to wrap, we can use custom rules that yield
the same return types as using decltype to avoid these issues.

This avoids using std::declval<T>() or alternatives like T() or T{},
which do not work with all compilers.

This allows to drop the dependency on ROOT/RStringView.hxx.

This is to avoid incompatibilities with older compilers that may arise
from using std::string_view and ROOT's backport of it.

The interface switched from iterator to const_iterator in C++11,
but GCC 4.8 still uses the old interface and breaks with the error
below if const_iterator is used:

error: no matching function for call to
  ‘std::vector<char, std::allocator<char> >::erase(TVec<char>::const_iterator&)’
   iterator erase(const_iterator pos) { return fData.erase(pos); }
                                                           ^