split internal dates methods into separate functions

[aplavin]

These methods are clearly internal: not documented, and with unclear semantics in the general case.

They lead to weird results instead of errors:

julia> using Unitful

julia> yearmonthday(1u"°")
(0.0, 12.0, 31.017453292519917)

julia> using Measurements

julia> yearmonthday(100±1000)
(1.0 ± 0.0, 4.0 ± 0.0, 10.0 ± 1000.0)

So, would be best to really remove them from public functions (hope noone relies on them).

[aplavin]

bump

[giordano]

Loads of tests have been broken by this PR, it shouldn't have been merged, I'm going to revert it

[giordano]

@aplavin this PR is now reverted. You're welcome to resubmit again a working version, but all tests and checks were failing to your changes well before your bump, and this PR shouldn't have been merged in that state. Please be more careful next time and fix the breakage before bumping.

[aplavin]

Sorry, I guess I just got used to tests often being broken unrelated to the changes in PRs, and didn't look into them...

These specific changes obviously don't introduce any new functionality. I submitted them for the sole reason of getting an error message instead of a weird result back, when passing unexpected types to these Dates functions.
Didn't expect this to produce test breakages at all, I guess moving these methods is not that important and isn't worth the risk. It's definitely not the worst case of "correctness bugs" :)

[LilithHafner]

I think these changes are appropriate, we just also need to adjust the CI tests to allow for them, and run nanosoldier to make sure people don't actually rely on them.