refactor(MdDatepicker): Better flow

[VdustR]

• Upgrading date-fns to 2.0.0-alpha.7
  For using new parser API because we have custom date string format
• Better naming and structure for inputDate(the string from input), localDate and value(from v-model)
• New feature: v-model supports number and string now, and its type is reactively modifiable via changing the type of v-model or changing the new props :md-model-type.
  Including documentation
• Debounce for input (will be conflicted with feat(MdDatepicker): Debounce the conversion into a date object #1666. I'll add that props after it merged)

BREAKING CHANGE: upgrade date-fns to 2.0.0-alpha.7

fix #1689

[marcosmoura]

@VdustR I think this is not good with the HTML5 standard unless we provide a "format" prop. To pass something like "dd/mm/yyyy". Do you think you can implement something like that?

[VdustR]

Do you mean another props format besides vue material configuration locale.dateFormat?

[marcosmoura]

I mean, we should document the locale.dateFormat.

[VdustR]

I added date format option into basic example. Additionally, I think there could be another page(or somewhere else) to explain all vue material options. How do you think?

[marcosmoura]

@VdustR I agree with you on that New Page thing. Do you think you can do that? It can be on a new page called "Configure" after the getting started.

[marcosmoura]

Maybe is better to be "Global configuration".

[marcosmoura]

This can also be a table with the API. What do you think?

[VdustR]

I don't know. The configuration object is nested. I'm afraid that it can't be described its structure clearly with table.

[hastom]

@VdustR @Samuell1
This PR breaks datepicker completely.
I think as it was early alpha date-fns formats were just buggy, so behavior of datepicker on current dev branch looks like this:

Also date-fns date formats changed after alpha.7