Allow editing of unscheduled downtimes that started over 48 hours ago

[ElliottKasoar]

Resolves #57

The main change is to the check of start dates older than 48 hours. This now (inelegantly) only applies when creating a new downtime, or when editing the start of a downtime, with more descriptive error messages added. This allows ongoing, unscheduled downtimes older than 48 hours to be edited (e.g. bringing the end date forward) but prevents the start date being changed once a downtime has been ongoing for 48 hours.

I have also added a check preventing editing of the end date into the past, as suggested in #57, although this feels slightly inconsistent, as it is currently possible to create downtimes that have finished.

This change does not allow editing of scheduled downtimes, as these cannot be edited in any way from 24 hours before they start. Allowing (limited) editing would be a much more substantial change. However, both scheduled and unscheduled downtimes can still be ended with immediate effect through a separate process.

This also has no effect on the creation of downtimes, so it is still not possible to create a downtime older than 48 hours, but this appears to be the intention of the check, and it would be straightforward to change this if desired.

More generally, I think more consistency in the validation would be useful, including (re)syncing the live validation of dates when editing a downtime to include all the current checks, and potentially reconsidering where all the different checks are handled within the code.

Note: Unfortunately, I will not be able to dedicate any significant time to further testing/responses, so I've made this a draft, but I think it worked as described, and thought it was worth sharing.

[GRyall]

although this feels slightly inconsistent, as it is currently possible to create downtimes that have finished.

Once it is submitted, it has been advertised, so changing it seems inappropriate. Creating a new one is more like recording the fact something has happened.