Adds DateRangePickerInputController component

[majapw]

to: @moonboots @ljharb @lencioni @airbnb/webinfra

This is the counterpart to #167.

I will update the PR description there with this same information, but the general idea is that I want to change the structure of the DateRangePicker (and eventually the SingleDatePicker as well) to this:

The motivation behind this is to increase the compose-ability of the library. We have seen a lot of instances where a user might want to swap out the input styles, or might want the DayPicker with all of the styles and rules that we default to in range, but different visibility rules.

As a result, the following will become true:

• DateRangePicker strictly controls the interactions between the inputs and the picker, ie when to show and hide the picker according to a default standard of rules
• DateRangePickerInputController controls any date verification, focus change, and keyboard input logic as related to the inputs.
• DateRangePickerInput renders the inputs to the page with the appropriate styles and has styles applied if you were to pass in a different focus state as a prop. It also has callback for user interaction, but ultimately is a fully controlled component.
• DayPickerWithModifiers contains state for hovering as well as logic for what to do when you click on a start date after an end date, and other date selection scenarios. It contains a modifiers object that applies styles accordingly. Most importantly, it does not contain callbacks for user interactions on the CalendarDay objects.
• DayPicker is a vanilla version of the calendar that renders it to the page, but has no styles or callbacks or state hooked up. It takes in all of these as props and allow you to roll your own implementation basically.

One advantage of this set-up is that it allows us to do the following if you want:

Basically, if you want to add any sort of panel or more information to the DayPicker you can. You can create your own custom show/hide logic, insert your own inputs easily, always show the DayPicker if you want and so on.

[coveralls]

Coverage increased (+0.3%) to 86.606% when pulling 790a1f8 on maja-add-DateRangePickerInputWrapper into 462c8bb on master.

[moonboots]

Thanks @majapw! Could DayPickerWithModifiers be baked directly into DayPicker? Most of the modifiers seemed universally useful, and folding these components could simplify the hierarchy (and naming).

I'll test out this branch locally to see if there are any issues integrated the separated halves into the current filter bar we're working on.

[majapw]

Nope. No can do, because the modifiers for the SingleDatePicker are different. This is why we still need a vanilla DayPicker and why I need to rename this to something like DayPickerWithRangeModifiers but also maybe something less verbose.

Plus there's no real difference between requiring DayPickerWithModifiers vs. DayPicker is there?

Also you should probably wait until both this and the input wrapper are merged in.

[lencioni]

Regarding naming, for DateRangePickerInputWithHandlers what do you think about DateRangePickerInputController?

[coveralls]

Coverage increased (+0.3%) to 86.606% when pulling 1286c4b on maja-add-DateRangePickerInputWrapper into 231342a on master.