Improve initial startup time by only performing layouts after a small batch of controls has been added. Suspending layout helps save CPU time but performing an occasional layout prevents the UI freezing for a couple of seconds once loading completes if it has to layout everything at once.

Also initially set the location of the control so that it will not appear in the panel area, saving a paint and making loading appear a bit cleaner.
Removed events using CollectionItemChangedEventArgs from AnimationLoopBase, preferring to instead call on the collection based event and provide the single element in a wrapped collection. This simplifies life for consumers since they cannot accidentally miss subscription to either event.

This fixes a bug in Editor2PonyAnimator which had subscribed to the single event, and would no longer update the info about the preview pony. This was because the pony was being add via the bulk insert and thus the collection based event was being raised with a single element instead. Now there is only a single pair of events to worry about this cannot happen in future.
Fix a bug in UnscalableImagesForm where the background loading would attempt to call SmartInvoke after the form had been closed.

To mitigate this problem in future, SmartInvoke will now perform a disposed check on the control. This prevents calls from the UI thread executing for a disposed control. Unfortunately for cross thread calls a race condition still exists. If the control is disposed after the call to InvokeRequired, an exception is thrown from BeginInvoke as a window handle cannot be found. Worse, if the control is disposed before the call to BeginInvoke then InvokeRequired will return false and will not throw - meaning we will try and directly execute the method on a thread other than the UI thread for a control that is disposed. This is an incredibly unfortunate race condition that cannot easily be mitigated.
Remove non x86 configurations (since mono requires this).
Reworked SmartInvoke methods into a more robust TryInvoke method after some investigation into how Controls handle and process invoke calls. The new design accounts for the fact that the caller cannot possibly guarantee the control will be valid for accepting invoke commands since it runs on its own thread and is capable of disposing itself. It returns a value indicating whether the action to execute was in fact run, and takes care to only run the action if the control has a window handle by the time things are marshaled to the UI thread. If some extraneous exception occurs due to race conditions (e.g. the control is disposed whilst the posting is in progress) then this is not allowed to propagate since it is not the callers fault.

Instead, the caller can check the return value if this means it can take some action (for example, background processing threads can use that as a sign to cancel their work since the UI has gone away).
Sort the random pony to the top of the selection area, and exclude it from the 0/1 buttons.