Handle "dec-2031" and "2031-dec"

Merge pull request #65 from ijt/issue/64/dec-2031

Issue/64/dec 2031

Fix directionality of MMM-DD dates

For example, for now=time.Date(2022, 11, 1, 0, 0, 0, 0, time.UTC), and direction=future, we get time.Date(2023, 3, 24, 0, 0, 0, 0, time.UTC).

Handle dates like mar-24

Merge pull request #61 from ijt/issue/60/mar-24

Issue/60/mar 24

Handle ranges with dashes such as 2016/08/01 - 2016/08/31

That's it, that's the release.

End explicit ranges at the start of the second implicit range

This seems more intuitive than ending at the end of the second range as it was doing before.

Check for sane range on day of month

This release adds a check for days of month being between 1 and 31.

Handle "1st", "2nd", "3rd", "4th" etc. days of month

This release closes issue #50.

Bug fix for issue 48

This release fixes a bug that led to "oct nov" being parsed as a single date.

V2 with a hand-written parser and 106x speed increase on a benchmark

Here are some notable changes in this release:

• no external dependencies
• parsing is hand-written for clarity, flexibility and speed
• 106x speed increase over v1, as measured by the Jabberwocky fragment benchmark
• 100% test coverage
• fuzz tests
• mostly dropped support for parsing times for now (except RFC3339), focussing on high-speed natural date parsing
• faithful whitespace preservation in ReplaceAllRangesByFunc
• provision of the exact original string fragment giving rise to the range in the user-provided func passed to ReplaceAllRangesByFunc, so callers can opt out of replacing anything they want by just returning the original fragment

Performance boost by reducing regex compiles

This version uses a new version of ijt/goparsify that reduces the amount of time spent compiling regular expressions, resulting in a 9.5x speed increase reported by the benchmark.