feat(datepicker): Add additional date adapter implementations

[jelbourn]

This issue tracks creating additional date adapter implementations in addition to the existing MomentJS implementation. Libraries to consider include:

• Luxon
• date-fns
• Day.js

[andriyor]

Consider of using date-io

[ahmadalfy]

Voting for date-fns. Moment.js entered maintenance mode.

+1 @ahmadalfy go for date-fns!
It's lightweight & fast.

[mtpultz]

I'm hoping by subscribing to this feature request for updates with Moment entering end of life that this doesn't mean I'm going to get a bunch of emails with everyones vote/opinion on which adapter implementation should be considered based on your own personal preference. Seems more logical to expand the list put forth by @jelbourn like @andriyor has since it wasn't included in the original list, but not voting individually through posts

[bbarry]

I am wondering if the material components repo is the right place for these things. IMO material should publish the api interface and encourage community contributions for the adapter services. Perhaps an endorsement program or something would be nice with a path to being mentioned in the documentation (a similar system could be useful for a number of projects that I've seen die stale code deaths from lack of updates because the projects fail to gain notoriety for the tiny enhancements they bring to the material ecosystem).

I'm assuming that the moment adapter exists due to use within Google. The only benefit I see to having it in this repo is to gain access to Google's robust build and package system (not always a benefit either; complexity always sucks) and maybe access to some test cases that aren't made public. If those aren't going to advantage these additional implementations then there seems little point to supporting them here (outside the notoriety angle which I think is a PR issue and not really a technical one).