Fix crash when creating SwingRedrawer on DirectX (#917) ### Changes Throw `RenderException` when constructing `Direct3DSwingRedrawer` with `nullptr` device. (Similar to `Direct3DRedrawer`) To avoid crash in: ``` DirectXOffscreenDevice *d3dDevice = fromJavaPointer<DirectXOffscreenDevice *>(devicePtr); GrD3DBackendContext backendContext = d3dDevice->backendContext; return toJavaPointer(GrDirectContext::MakeDirect3D(backendContext).release()); ``` ### Fixes Speculative fix for crash with a stack head below: ``` --------------- T H R E A D --------------- Current thread (0x000001cbcb0793f0): JavaThread "AWT-EventQueue-0" [_thread_in_native, id=16744, stack(0x0000009488c00000,0x0000009488d00000)] Stack: [0x0000009488c00000,0x0000009488d00000], sp=0x0000009488cfc670, free space=1009k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [skiko-windows-x64.dll+0x58afa] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.jetbrains.skiko.swing.Direct3DSwingRedrawer.makeDirectXContext(J)J+0 ``` ### Note I've found suspicious place in ```kotlin // RedrawManager.kt:30 _renderApi = fallbackRenderApiQueue.removeAt(0) _redrawer = redrawerFactory(_renderApi, redrawer) ``` Seems like `redrawer` is disposed twice if `redrawerFactory` throws (both paths constructing `RedrawerManager` are affected). @igordmn can you have a look? It's a universal path for all desktop users, so I wonder why it didn't backfire, if it's indeed incorrect. May be it's because we don't really call `redrawerFactory` if a redrawer was constructed correctly, so disposal of old one doesn't ever get called in this context. I'm not sure where are the invariant boundaries here.