New threading model

[andydotxyz]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

To work on race conditions and many locking challenges we agreed to revise the threading model (the "App thread").
This issue tracks the work required.

Is it possible to construct a solution with the existing API?

No response

Describe the solution you'd like to see.

• Re-merge draw and event into one thread (Revert using a separate draw thread #4656)
• Move animation ticks to the main thread (Revert using a separate draw thread #4656)
• Fix issues with re-draw on window resize that led to draw/event separation
• Check that all widget callbacks happen on this same thread
• Combine data binding into same thread
• Add ability to schedule code on the App thread (new "fyne.Invoke" API, name TBD)
• Revise unit testing to do this all sync and remove waits etc no longer needed
• Back out the BaseWidget.SetFieldsAndRefresh API - it will be obsoleted by "fyne.Invoke"
• Clean up now-unneeded locks/synchronization in widgets, etc
• Consider adding a noCopy struct that is a dummy implementation of sync.Locker to BaseWidget so go vet can still complain about passing widgets by value

[dweymouth]

Re-merge draw and event into one thread

This might be the easiest path, but it isn't necessarily the only one. We can keep them on separate threads as long as we have them lock when reading or writing state.

That being said, unless we need to work around platform issues (ie #2 on the checklist), merging them to one thread might be the way to go.

I'll also add another checklist item for removing all the now-unneeded locks/sync stuff throughout the codebase

[andydotxyz]

Re-merge draw and event into one thread

This might be the easiest path, but it isn't necessarily the only one. We can keep them on separate threads as long as we have them lock when reading or writing state.

Yes, there could be locking based solutions - but part of this is trying to find the simplest solution, so reverting the thread split seems like a good start.