Fix resizing of TUI python windows

Fix resizing of TUI python windows

When resizing from a big to small terminal size, and you have a
TUI python window that would then be outside of the new size,
valgrind shows this error:

==3389== Invalid read of size 1
==3389==    at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167)
==3389==    by 0xC3E3C9: wrefresh (lib_refresh.c:63)
==3389==    by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134)
==3389==    by 0x98921C: tui_py_window::rerender() (py-tui.c:183)
==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389==    by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033)
==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389==    by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81)
==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389==  Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd
==3389==    at 0x4A0A430: free (vg_replace_malloc.c:446)
==3389==    by 0xC3CF7D: _nc_freewin (lib_newwin.c:121)
==3389==    by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78)
==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389==    by 0x8E40E9: captured_command_loop() (main.c:407)
==3389==    by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324)
==3389==    by 0x62AC04: main (gdb.c:39)

It's because tui_py_window::m_inner_window still has the outside
coordinates, and wnoutrefresh then does an out-of-bounds access.

Fix this by resetting m_inner_window on every resize, it will anyways
be recreated in the next rerender call.

Approved-By: Andrew Burgess <aburgess@redhat.com>