Added new interaction/display mode to treebox control.
Enabling use_entire_line the entire line of the treebox/child is used for mouse interactions and display purposes.
When the user opens a submenu containing items with the style `menu::checks::option` and clicks an option, the radio button logic doesn't work. This bug was discovered and fixed by nanapro.org forum user "huycan" (I'm just submitting the PR). See this forum post: http://nanapro.org/en-us/forum/index.php?u=/topic/1256/ggleave-a-menu-open
As mentioned in more detail in the forum post linked above, my understanding of why this happens is that `menu_builder::checked` fails because the `menu_window` of the submenu is created with the `menu_builder` object used by the parent menu.
This method incorrectly calculates the position of checkboxes in the listbox content area. It uses the formula `new_where.second * item_h + header_visible_px()` to calculate the number of pixels between the top of the viewport and a checkbox.
The problem is that when the first visible item is only partially visible, `new_where.second * item_h` produces an excess of pixels equal to the vertical segment of the first visible item that is not in the viewport. This excess value produces a downward displacement of the calculated checkbox position, so it must be accounted for in the aforementioned formula.
This problem occurs because at some point, the library switched from scrolling in item-sized increments to smooth scrolling (in older versions, it used to be that it was impossible for an item to be only partially visible).
Relevant thread: http://nanapro.org/en-us/forum/index.php?u=/topic/1227/ggnana-listbox-with-a-check-box-for-each-list-item#post-3359
When a tab is deleted using `tabbar::erase`, `trigger::erase` is called. This function does not call `API::refresh_window` if the tab was erased successfully (unlike `trigger::tab_color`, `trigger::tab_image`, etc.), thus the tab is still visible until an interaction is made (like mouse click on `tabbar`).
