Clarify our OOP semantics across the codebase (#9586)

Basically:

* Use `extend` for class definitions
* Use `new` for object instantiations

That includes some minor code cleanups along the way:

* Updated `Widget`'s docs to make the semantics clearer.
* Removed `should_restrict_JIT` (it's been dead code since https://github.com/koreader/android-luajit-launcher/pull/283)
* Minor refactoring of LuaSettings/LuaData/LuaDefaults/DocSettings to behave (mostly, they are instantiated via `open` instead of `new`) like everything else and handle inheritance properly (i.e., DocSettings is now a proper LuaSettings subclass).
* Default to `WidgetContainer` instead of `InputContainer` for stuff that doesn't actually setup key/gesture events.
* Ditto for explicit `*Listener` only classes, make sure they're based on `EventListener` instead of something uselessly fancier.
* Unless absolutely necessary, do not store references in class objects, ever; only values. Instead, always store references in instances, to avoid both sneaky inheritance issues, and sneaky GC pinning of stale references.
  * ReaderUI: Fix one such issue with its `active_widgets` array, with critical implications, as it essentially pinned *all* of ReaderUI's modules, including their reference to the `Document` instance (i.e., that was a big-ass leak).
* Terminal: Make sure the shell is killed on plugin teardown.
* InputText: Fix Home/End/Del physical keys to behave sensibly.
* InputContainer/WidgetContainer: If necessary, compute self.dimen at paintTo time (previously, only InputContainers did, which might have had something to do with random widgets unconcerned about input using it as a baseclass instead of WidgetContainer...).
* OverlapGroup: Compute self.dimen at *init* time, because for some reason it needs to do that, but do it directly in OverlapGroup instead of going through a weird WidgetContainer method that it was the sole user of.
* ReaderCropping: Under no circumstances should a Document instance member (here, self.bbox) risk being `nil`ed!
* Kobo: Minor code cleanups.

frontend/device/android/device.lua

@@ -67,7 +67,7 @@ local external = require("device/thirdparty"):new{
     end,
 }
 
-local Device = Generic:new{
+local Device = Generic:extend{
     isAndroid = yes,
     model = android.prop.product,
     hasKeys = yes,
@@ -111,21 +111,6 @@ local Device = Generic:new{
             android.dictLookup(text, app, action)
         end
     end,
-
-    -- Android is very finicky, and the LuaJIT allocator has a tremendously hard time getting the system
-    -- to allocate memory for it in the very specific memory range it requires to store generated code (mcode).
-    -- Failure to do so at runtime (mcode_alloc) will *tank* performance
-    -- (much worse than if the JIT were simply disabled).
-    -- The first line of defense is left to android-luajit-launcher,
-    -- which will try to grab the full mcode region in one go right at startup.
-    -- The second line of defense is *this* flag, which disables the JIT in a few code-hungry modules,
-    -- but not necessarily performance critical ones, to hopefully limit the amount of mcode memory
-    -- required for those modules where it *really* matters (e.g., ffi/blitbuffer.lua).
-    -- This is also why we try to actually avoid entering actual loops in the Lua blitter on Android,
-    -- and instead attempt to do most of everything via the C implementation.
-    -- NOTE: Since https://github.com/koreader/android-luajit-launcher/pull/283, we've patched LuaJIT
-    --       to ensure that the initial mcode alloc works, and sticks around, which is why this is no longer enabled.
-    should_restrict_JIT = false,
 }
 
 function Device:init()