Move moment to peerDependencies

[Kerumen]

Supersedes #419

Fixes #122

It's better to move moment to peerDependencies because it prevents duplication of moment instances which can leads to bugs (when loading locals for instance).
In our project, we have a fixed dependency of moment@2.18. react-datepicker installs moment@2.19 so 2 instances of moment are loaded and locals doesn't work for the moment of react-datepicker.

If you look at react-dates, this is how they require moment: https://github.com/airbnb/react-dates/blob/master/package.json#L126

I also removed package-lock.json as it's not used in the project anymore. Tell me if I should remove this from the PR as it's not quite related (but I didn't know which lockfile to update so I thought it should be better to delete it).

[martijnrusschen]

I agree this is probably better, however there's some discussion going on here #122.

[martijnrusschen]

Not sure if we can make this change without breaking everyone's datepickers. What do you think?

[codecov]

Codecov Report

Merging #1168 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1168   +/-   ##
=======================================
  Coverage   85.36%   85.36%           
=======================================
  Files          13       13           
  Lines         888      888           
  Branches      146      146           
=======================================
  Hits          758      758           
  Misses         42       42           
  Partials       88       88

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d513e83...b6bea21. Read the comment docs.

[Kerumen]

Some discussion which ended 1 year and a half ago. I think this should be reconsidered.

I think that everyone who uses the datepicker are already using moment but if we want to be truely semver compliant, this can be released as a breaking change (major).

[aij]

@Kerumen I think the plan is to bump the major only when we think the API is stable. Keeping it at 0 is also truly semver compliant since semver says

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

[Kerumen]

@aij Yes, seems legit too. npm won't auto-upgrade people and if they manually do it, they will know why their code breaks (if it breaks).

[martijnrusschen]

Okay lets do this. We use yarn.lock instead of the package-lock.json, so lets make sure that's updated.

[martijnrusschen]

@Kerumen Let me know if you want to proceed with this, happy to merge now we're reaching consensus.

[Kerumen]

@martijnrusschen Conflicts resolved. I set ^2.0.0 as semver hence people won't have warnings if they install a previous version than 2.19.4. I suppose all moment >=2 works.