Drag and drop always assumes to have [NSWindow contentView] with drag drop API

In our products we reparent a QWindow's underlying native view onto a foreign host window by using QPA's setEmbeddedInForeignView API, which in general works fine.

Unfortunately, the current Qt/Cocoa implementation of drag and drop in the case of multiple dragged items/flavors makes a hard assumption on the existence of a [_NSWindow contentView_] with the required drag and drop Cocoa API.

Qt's macOS QDrag implementation has a certain dispatching mechanism, when it comes to starting a drag operation:

• There is a check named maybeDragMultipleItems which not only checks the number of dragged items, but also the availability of this certain API on NSWindow's contentView
• In our cases (our standalone windows typically attach NSView's  to the default contentView, and plug-in UIs are attached to the host's NSView (could be the contentView or not )
• If this API is not found, Qt's drag implementation will fallback to an outdated API  only supporting single drag items
• This will internally (silently) crash  if there are multiple drag items involved, and leaving the app/plug-in in a broken state 

I will attach a patch, which solves the drag and drop dispatching for our use case and 100% compatible to the default mechanism. 

• The Qt6 drag operation not only has access to the last mouse event being cached, but also the NSView (m_lastView)  from which the drag operation did start
• This should take the priority when being inspected for the existence of the required drag and drop API.
• Only if it is not available, the fallback approach to query the contentView of the NSWindow should be taken.

Pick-targets:

• 6.2
• 6.3