Calculate proper `(start, end)` period based on the inferred `datetimev2`

[simone3991]

This closes #71

At TimeSurveyBotLuisEx.cs, the WorkedPeriod() computation can be further improved.

public (DateTime start, DateTime end) WorkedPeriod(double minutes, string culture = Culture.English)
{
    var workedPeriodInstances = Entities._instance.datetime;
    if (workedPeriodInstances.Length > 1)
    {
        string? instance = workedPeriodInstances[1].Text;
        var recognizedDateTime = DateTimeRecognizer.RecognizeDateTime(instance, culture).First();
        var resolvedPeriod = ((List<Dictionary<string, string>>)recognizedDateTime.Resolution["values"])[0];
        // TODO: use resolvedPeriod to pick a (start, end) period
    }
    return (DateTime.Today.AddHours(9), DateTime.Today.AddHours(9).AddMinutes(minutes));
}

the resolved period represents an indication from the user of when the Clockify entry should be inserted.
Normally, this indication is not present, and the period fallbacks to the start (9AM) of the current day.

When one exists, however, the fallback is not needed. For example. the user might type "tomorrow", or "from 4 PM" or "last monday". The engine to commute these sentences into an actionable data object is provided by Microsoft, and the result is written in the resolvedPeriod variable. Check here to know more.

What needs to be added is the transformation of the library ModelResult instance into a (start, end) tuple.
This transformation should consider that:

• duration indications (such as "2 hours") should result in exception, as they wouldn't make sense (the duration of the time entry is already known, it is minutes, and it can't be overridden here)
• range indications are good, but they can't in any way conflict with the minutes parameter, which indicated the duration for the entry. Which means that whatever the function does, it should guarantee that (end - start).TotalMinutes() == minutes.

The solution should be properly documented and checked by unit tests, with at least these cases:

last monday	Period starting from last monday at 9, ending after {minutes} minutes
last friday at 4pm	Period starting from last friday at 4, ending after {minutes} minutes
till 11 am	Period ending at today 11 am, starting {minutes} minutes before
for 60 minutes	Should return an error, because duration can't be accepted
from 9 am to 10 am	Should return an error if {minutes} does not equal exactly 60

Note
Do not worry about timezone, think in local time for the user.
Localization will be taken care of separately (#81)