dateformat with month/day config and month/day in the past uses current year, option to use next year

#### To request a feature...

* Clearly describe the feature.
* .taskrc setting of ```dateformat=db```
* This allows, e.g. ```2sep``` for September 2nd
* If current year is 2020, and ```task 1 modify scheduled:2sep``` is executed
* Currently, no mater what the current date is when that command is executed, the scheduled date will be set to a year of 2020
* It would be nice to have a setting, say ```dateformat.relative_year```, when, if enabled, and the user has a ```dateformat``` setting that doesn't include the year, then the year would be determined as such:
* If the entered date and month is before the current date and month of the current year, then use the following year when generating the final date
* If the entered date and month is after the current date and month of the current year, then use the current year when generating the final date
* Clearly state the use case. We are only interested in use cases, do not waste time with implementation details or suggested syntax.
* It's currently December 29th, 2020
* I execute ```task 1 modify scheduled:5jan```
* It would be nice if the calculated date could be configured to end up as 2021-01-05, but currently there's no option, and the calculated date is always 2020-01-05
* The idea is that it's much more common when declaring a month and a day, that it would refer to a month and day in the future, not the past, so date formats with only a month and a day should have the option to be configured for that behavior.

I poked around ```Datetime.cpp```, and I see this:

```c
// When true,
// - HH:MM:SS is assumed to be today if the time > now, otherwise it is assumed to be tomorrow.
// - day name is converted to date relative to now
// - 1st, 2nd, 3rd, ... is converted to date relative to now
// When false,
// - HH:MM:SS is always today.
// - day name is always converted to date before now
// - 1st, 2nd, 3rd, ... is always converted to date before now
bool Datetime::timeRelative = true;
```

...and this seems like a good fit for the behavior I'm describing above.

I'm even willing to help implement the feature, but I can't really make good sense of that file or where to start implementing it.