Avoid stuck action logs if multiple changes in quick succession

[timalces]

Aims to resolve #61

After some investigation, it was found that if an instance is switched on and off again (or vice verse) in quick succession, there is a small chance that the related action logs will become stuck in a 'pending' state, if instance status is not checked & recorded before the second action completes. E.g.

• Instance is off as of 17:00
• Turn on instance at 17:01
• Turn off instance at 17:02
• Instance is successfully turned on then turned off
• Instance status is checked at 17:05. It is off, so it appears to have not changed. The instance log is therefore not updated
• The related action logs are checked if complete. But as this requires an instance log with both the target status, and an updated_at time after the action log was created, the conditions are not met. So they remaining pending

This PR resolves the problem by adding last_checked to InstanceLogs, set every time the task instance_logs:record is run. This is used instead of updated_at when determining if an action log's target status has been reached. The existing complete_previous method/workflow ensures any earlier pending action logs for the same instance are also marked as completed.

To prevent this also resulting in the new data check being triggered every time instance statuses are checked, a new field last_status_change is also added to InstanceLogs, and this used for the data check rather than updated_at

[timalces]

Merging this as appears to have fixed the problem.