v0.7 release candidate

Today I sent a link to a v0.7 rc to some brave beta testers, it should fulfill *all* requirements of the bounty.

Main changes compared to the 0.6 on IcAROS:
- public screens are working (again)
- mouse pointer gets hidden (if AROS supports it)
- MUI menus work now
- popup menus (done via real intuition windows as in MUI) work now
- re-enabled old sound code, which (according to clusteruk) even works
- fixed garbage shape window, if toggled integration
- added more resolutions
- destroyed uae window content is now restored correctly
- uae integration now works, if you use assigns as hardfiles
- 68k apps should be able to start from amidock, if j-uae is running already

MUI part #2

Next thing I noticed was, that MUI popup menus were not working, too. So I had some debugging fun to find out, how MUI does those nice popup menus..

If you click on an object with a popup menu (RMBTRAP set)
- MUI opens a new intuition window for the popup menu
- MUI opens it INACTIVE
- the popup window does not get any mouse move messages, as it is not active
- I assume, it reads the mouse coordinates itself or gets them forwarded by the main window
- as soon as you click in the popup window, it is activated
- if you activate a popup window, it reports the selected item back and closes itself

Nice magic, maybe that's one of the reasons for the name of this toolkit ;).

So I had to make all that possible for integrated j-uae windows, too. Open inactive windows, let them get mouse moves, keep the right button pressed all the time and so on. But now, they work:

MUI part #1

I was on the search for an application, which really uses public screens. Not so easy for someone, who did not use AmigaOS for quite some time ;). But of course, every MUI application can run on a public screen. Just use the settings menu .. SETTINGS MENU!?

No MUI application had menus, if run in j-uae integration mode :(.

I noticed, that some application might change their WFLG_RMBTRAP flag for every mouse move.. if the application wants a normal intuition menu, it clears the flag, as soon as the mouse moves over a gadget, which handles right clicks itself, it clears it. So for every mouse move, MUI asks the underlying gadget, if it has a popup menu or something like that. Btw, ZUNE does it the same way..

Not really elegant as you could just always have WFLG_RMBTRAP cleared and in case someone picks a menu over such a gadget you can always send a MENUCANCEL and get the same effect. You then receive the same message again, as if WFLG_RMBTRAP was set. You just have do do this on every mouse click and not on every mouse move.. Maybe I should try, if it really can work the other way in ZUNE..

Anyways, MUI seems to do it for every mouse move :( and so integration had no chance to notice it.

For the AROS side, we do it the elegant way now: If we get a MENUVERIFY message, we look at the according aos3 window. If it has WFLG_RMBTRAP cleared at the time of the mouse click, we display an according AROS intuition menu.

If WFLG_RMBTRAP is set in aos3, we just send a right click event to the aos3 window.

So now all MUI windows have working Intuition menus :).