These three files are used as entry points into the project, and we
expect people to be importing them directly so they are at the top level
for convenience. Because of this, they have not been getting run through
Babel like the rest of the code here, so they were using older syntax.

In this commit, I am moving these files into the src directory so they
will be built into lib like the rest of the code here. In their place at
the top level, I am creating some very light shims that simply bring in
the built version of the module and re-export it if necessary.

This gives us a couple of advantages. First, it makes more of our code
consistent. Second, it makes it possible to produce two different kinds
of builds, one for CommonJS consumers and another for ES modules
consumers.

Addresses #648.

* Add `openDirection` prop to `<DateRangePicker/>`, `<SingleDatePicker/>`, `<DateRangePickerInputController/>`, `<DateRangePickerInput/>`, `<SingleDatePickerInput/>`, `<DateInput/>
* Add SCSS variables for input font size, padding, etc. (used in calculation for open-up absolute positioning)
* Add stories and tests for new prop

Fix #625 - Rename AFTER_POSITION to ICON_AFTER_POSITION to be consistant + Use constant instead of string

Instead of passing down an object of modifier string => modifiers functions to each CalendarDay component and expecting the CalendarDay component to take care of updating itself, we now put the burden on the top of the tree instead of on the leaves. The previous model basically ended up meaning that whenever an interaction happened on an individual day, even a hover interaction, every single CalendarDay would have to recalculate its modifiers and rerender as a result. This was, as you can imagine, really god damn slow.

In this new model, the DayPickerRangeController maintains a map with the following structure:
```
{
  MONTH_ISO_1: {
    DAY_ISO_1: Set(['modifer_1', 'modifier_2', ...]),
    DAY_ISO_2: Set(['modifer_1', 'modifier_2', ...]),
    ...
  },
  ...
}
```
It passes this down the tree such that each `CalendarMonth` and each `CalendarDay` only gets the information that pertains to it. This means that the updating of these modifiers is also handled at the top-level and is done in the `componentWillReceiveProps`, `onDayMouseEnter`, and `onDayMouseLeave` methods of the `DayPickerRangeController`. Fortunately, this allows us to more finely tune which days get updated and speeds up the rerendering/updating process dramatically.

- Adds screen reader text to the input to describe how to enter the calendar
- Adds arrow navigation to the calendar itself
- Adds a keyboard shortcuts panel that pops up on top of the calendar
- Adds screen reader text to each CalendarDay

DateRangePicker and SingleDatePicker have a new prop, directionAnchor
that will align the components to the left/right side of the page.
This prop has two new constants, DIRECTION_ANCHOR_LEFT (default)
and DIRECTION_ANCHOR_RIGHT.

This should allow consumers to do `import { START_DATE, END_DATE } from 'react-dates/constants';` which is ideal