[3.0] Consider removing render cache and make widgets maintain a reference to their renderer

[dweymouth]

Checklist

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

Describe the bug

See discussion in #5112 for problems with the current approach of renderers being kept track of separately from widgets. It would be simpler and probably lead to fewer bugs if widgets kept a reference to their renderer and created only one renderer per widget ever, and the renderer just gets GC'ed along with the widget

How to reproduce

n/a

Screenshots

No response

Example code

n/a

Fyne version

2.x.x

Go compiler version

n/a

Operating system and version

n/a

Additional Information

No response

[andydotxyz]

Given that widgets can stay in memory for a very long time, but that their renderer should live only as long as they are visible I'm not sure this is a desirable change.
In addition having widgets retain a reference to their renderer would introduce the likelyhood of circular reference paths because the typical workflow is update widget -> call refresh -> renderer updates. But if you know your renderer and ask it to do things then it can refresh causing something else to update and trigger a further update.
Would it not also get in the way of the idea that we want to be able to synchronise state? If renderers were updated by their widgets directly then the graphical state is unknown.