Release v4.24.0

It seems that the problem is that, sometimes (not always) Windows recreates the tree view displayed in the overview pane and all its nodes. The tree view nodes are custom classes that have a property that reference an `IView` instance relating to the displayed items. Unfortunately when Windows recreates the nodes the `IView` property is set to `nil`.

This explains the nil `IView` references that have been causing the access violation.

The solution used in the fix is to handle the Windows messages sent when the computer hibernates and resumes. On hibernation the state of the tree view is recorded. On restoration we assume that the tree view is corrupted and so forcibly rebuild it and restore the saved state.

There is a problem thought. The message we handle is issued twice after resuming from hibernation. There is no easy way to tell which message has been issued. Therefore the tree view is rebuilt twice. There is not much performance penalty to this, so we can let it go. The potential problem is that if the tree view is recreated it happens after the 1st message and before the 2nd. Should, for example, the message only be triggered once then the bug will be back!

Even after all this it is possible that the program will redraw the tree view before the `IView` instances are restored. I've added code to the tree node custom drawing code to test if a node's `IView` instance is nil. This leads to some nodes not being drawn correctly. However, this doesn't matter because the tree view is forcibly redrawn again after the `IView` instances are restored.

All in all, I've not totally happy with this solution, which is more of a work around than a fix, but it's the best I can come up with without completely revising the overview frame code.

Fixes #70

Release v4.24.1

Following a discussion in the comments the DelphiDabbler Blog post at
https://tinyurl.com/mrp76mdy it seems that was not a good idea to rely
upon handling WM_POWERBROADCAST's PBT_APMPOWERSTATUSCHANGE event to
restore the overview pane's tree view nodes to the expected state after
Windows has recreated the tree view in an invalid state.

So I've modified the code to only rely on the PBT_APMSUSPEND event of
WM_POWERBROADCAST and not PBT_APMPOWERSTATUSCHANGE. PBT_APMSUSPEND is
handled to prepare for hibernation by not only saving the tree view's
state (as per the previous fix) but also setting an event handler that
gets called only when the tree view's window gets recreated by Windows
AND the treeview contains nodes with nil IView pointers. When called,
the event handler rebuilds the tree view with nodes containing valid
IView references.

The problem is that the event needs to be triggered from the
TTreeView.CreateWnd method that gets called when Windows recreates the
tree view. Since TTreeView exposes no suitable events, the only way is
to inject a suitable event using a nasty hack. Not good practise.

Note that all the methods that depend on the hack have been given names
beginning with "_HACK_" to make it obvious where the naughtiness lies.

Release v4.24.2 HOTFIX