ReaderFooter: Fix the madness related to its hold footer

Namely, instead of making it lower priority than readerhighlight and
hoping for the best, make it higher priority, as it should (ReaderFooter
itself is *above* Reader, after all), with a sane set of fallthroughs:

* No footer
* No hold-to-skim
* Held outside the footer (but inside the footer tap zone)

This made the crap workaround from #7466 unnecessary, and actually fixes
the behavior in PDFs (because readerhighlight will match the *physical*
page, which may include off-screen content) and ePubs w/r eclaim bar
height (in which case, there's actual content behind the footer that
readerhighlight could have matched on).

Fix #7697

frontend/apps/reader/modules/readerhighlight.lua

@@ -215,9 +215,6 @@ function ReaderHighlight:setupTouchZones()
             screen_zone = {
                 ratio_x = 0, ratio_y = 0, ratio_w = 1, ratio_h = 1,
             },
-            overrides = {
-                "readerfooter_hold",
-            },
             handler = function(ges) return self:onHold(nil, ges) end
         },
         {