ui_cocoa: cast [NSWindow contentView] to (NSView*) for bounds call

GCC 4.0 (Xcode 3.1, PowerPC) reports:

    ui_cocoa.m:629: error: incompatible types for argument 1
        of 'setFrame:'

The receiver-side cast added in 47a7fd4 was not the actual fix —
this error is from the argument side.  On the 10.5-10.9 SDKs:

    @interface NSWindow ...
    - (id)contentView;

contentView returns id, not NSView*.  (Apple changed this to NSView*
only in 10.10+.)  When GCC 4.0 sees [<id> bounds], it picks any
visible bounds selector — and cocoa_common.h imports
<QuartzCore/QuartzCore.h>, so both NSView (NSRect) and CALayer
(CGRect) are visible.  On 32-bit 10.5 NSRect and CGRect are
incompatible types, so whichever way GCC picks, half the callers
get a type mismatch.

Cast the contentView result to (NSView*) so its bounds call
resolves unambiguously to NSView's NSRect version.  Fix both
setFrame: call sites in the file (lines 629 and 726) at once;
they have identical shape and would otherwise fail in sequence.

Modern clang infers the correct type from receiver context; the
cast is a no-op there.

Author: LibretroAdmin

ui/drivers/ui_cocoa.m

@@ -626,7 +626,7 @@ - (void)applicationDidFinishLaunching:(NSNotification *)aNotification
    [self.window setNextResponder:_listener];
    self.window.delegate = _listener;
 #else
-   [(NSView*)[CocoaView get] setFrame: [[self.window contentView] bounds]];
+   [(NSView*)[CocoaView get] setFrame: [(NSView*)[self.window contentView] bounds]];
 #endif
    [[self.window contentView] setAutoresizesSubviews:YES];
 
@@ -723,7 +723,7 @@ - (void)setViewType:(apple_view_type_t)vt
    }
 
    _renderView.autoresizingMask = NSViewWidthSizable | NSViewHeightSizable;
-   [_renderView setFrame: [[self.window contentView] bounds]];
+   [_renderView setFrame: [(NSView*)[self.window contentView] bounds]];
 
    self.window.contentView               = _renderView;
    self.window.contentView.nextResponder = _listener;