Update JulianDate API consistency and rounding

[cusher]

Tests also done in a slightly more systematic way.

This has some breaking changes due to renaming methods and replacing constructors with static of methods. Not sure if it would be better to leave that alone (or keep and mark as deprecated instead), but it seemed like you had done the same in the branch already.

[igr]

Question @cusher: do you mind that JulianDate is part of the jodd-util?

If you think it makes sense, I may extract the class and add it to a separate repo instead?

[cusher]

@igr No, I don't mind. I'm just glad to have someone who is very responsive and cares about the library maintaining the project. However you decide to organize things is completely fine with me!

[neroux]

@igr, the thing that's not entirely clear to me is why the constructor was dropped? That seems to me like a rather unnecessary breaking change. Providing of itself is already a sort of duplication, but that's all right for those who prefer that over the constructor, but why dropping the constructor?

[neroux]

@igr?

[igr]

Hi @neroux! I don't have a strong opinion on this one. Here is how I see it:

• The only true ctor for JulianDate emphasizes the use of just Julian date (int, double pair)
• all of static ctors are some kind of converters, i.e. they do more than simple initialization.
• adding both of and ctors would just add more code, and with this number of variants, I feel it is a bit too much...

In short, this class is all about precise calculation; and I appreciated less code in this case, that is all. Not that I would make a rule from it :)

[igr]

@cusher please take a look at: https://github.com/igr/julian-day

I have redone the calculations and introduced long-needed separation of gregorian and julian calendars.