Adding a locale modifies the window object

[whatisaphone]

We're using react-datepicker in an app where the global context should not be modified. It looks like in v2, non-English locales won't work unless the locales are registered ahead of time on the global window object:

react-datepicker/src/date_utils.js

Lines 244 to 249 in ad499a2

	export function registerLocale(localeName, localeData) {
	if (!window.__localeData__) {
	window.__localeData__ = {};
	}
	window.__localeData__[localeName] = localeData;
	}

This does not align with how date-fns itself handles locales. In their docs, they have this example, where the locale object is passed directly as an argument, without going through an indirection layer:

var distanceInWords = require('date-fns/distance_in_words')
// Require Esperanto locale
var eoLocale = require('date-fns/locale/eo')

var result = distanceInWords(
  new Date(2016, 7, 1),
  new Date(2015, 0, 1),
  {locale: eoLocale} // Pass the locale as an option
)
//=> 'pli ol 1 jaro'

The react-datepicker equivalent would look something like this:

import eoLocale from 'date-fns/locale/eo';
import DatePicker from 'react-datepicker';

const MyComponent = () => (
  <DatePicker
    locale={eoLocale}
  />
);

Allowing that usage would let you manage locales with all the flexibility that date-fns itself allows. Supporting it in a backwards-compatible way would (at first glance) require only one change, here, to something like this:

export function getLocaleObject(localeSpec) {
  if (typeof localeSpec === 'string')
    // Treat it as a locale name registered by registerLocale
    return window.__localeData__ ? window.__localeData__[localeSpec] : null;
  else
    // Treat it as a raw date-fns locale object
    return localeSpec;
}

Can you think of any reason not to support this?