This is low-risk and will give us a little better bundle size and
runtime performance. More information:

https://babeljs.io/docs/en/babel-plugin-transform-classes#loose

This new version includes an option for removing propTypes, so I am
removing that plugin in favor of using the preset option.

This will help reduce the bundle size impact. Note that any consumers
who are depending on any react-dates components having a `.propTypes`
property will no longer work as expected after this change.

I enabled this using wrap mode, which adds `process.env.NODE_ENV`
checks, which is a pretty standard method for React apps. I believe this
will allow this library to have propTypes in development, but for them
to be minified out in production builds.

To make this safe to enable in this repo, I enabled the
react/forbid-foreign-prop-types ESLint rule, which was written
specifically for the benefit of this plugin.

Here's a diff showing what effect this has on the esm build:

  https://gist.github.com/lencioni/1b436d365570394ccde659c829ba02c3

[Dev Deps] update `@storybook/addon-actions`, `@storybook/addon-info`, `@storybook/addon-links`, `@storybook/addon-options`, `@storybook/react`, `babel-loader`, `babel-plugin-transform-replace-object-assign`, `clean-css`, `cross-env`, `eslint`, `eslint-plugin-import`, `eslint-plugin-react`, `moment`, `nyc`, `react-with-styles-interface-aphrodite`, `sass-loader`, `sinon`, `style-loader`

In https://github.com/airbnb/react-dates/pull/791 I added an ESM build,
but ended up breaking the production build for gh-pages. Storybook
builds with NODE_ENV=production, so this should fix that problem.

This ES modules build will make these modules smaller in the final
bundles, since the way Babel compiles import to require is pretty
verbose. Additionally, it will enable webpack to make some optimizations
on the final bundle, including tree-shaking and scope hoisting (if
enabled). These will improve bundle sizes and runtime performance.

I considered adding a module field to the package.json to point to this
version for folks who are able to use it, but I decided to wait on that
for now since that is still pretty experimental.

For now, consumers will need to use this either by importing from
react-dates/esm directly or by using something like a webpack alias to
use this version of the build.

When working on this I originally kept the plugins array at the top
level instead of repeating it for each env, but I ran into an issue that
seemed related to ordering that caused babel-register in the compile CSS
script to not apply the correct transformations. I was able to work
around this by repeating the plugins for each env.

I want to do some optimizations on how react-dates is built, to help
reduce the bundle size impact of using this project. The first step I
see is reducing the size of each of the components, which we can achieve
by avoiding building them with webpack.

From what I can tell, webpack was only brought in to support getting
SVGs in these components. We can pretty easily replace this with a Babel
transform that will achieve the same result, but with less complexity in
our build, and a little less overhead in the resulting components.

Before this change:

```
~/react-dates ❯❯❯ du -hs lib/components
420K    lib/components
```

After this change:

```
~/react-dates ❯❯❯ du -hs lib/components
348K    lib/components
```

Fixes #476.

also add cross-env + babel-plugin-istanbul for better coverage reports