[dwm] dmenu navigation with a lot of items.

Hi,

I love dmenu, but one thing has been bothering me for a while: lists
with a lot of items are hard to navigate. With a short list, you can
just browse through it with left/right; with a long list you can use
the filter to speed up navigation.
This is only true however when you already know what you're looking
for: typing 'fire' to quickly jump to firefox is only useful if you
already know that that's what you want _and_ that it's in the list. If
you are faced with a long list, in which you don't know exactly what's
in it, typing in a filter isn't really going to help, and scrolling
all the way through the list with --> is a big pita.
So from this pov, "It manages huge amounts (up to 10.000 and less) of
user defined menu items efficiently" (from the manpage) is only partly
true.
In order to solve this, I believe some shortcuts to make bigger jumps
in the menu are needed.
Attached to this mail is a pull request that uses PageUp/PageDown for jumping
back/forward a full 'page', and Home/End to jump to the first/last
item in the list. The pull request also updates the manpage accordingly.

Have fun,
Greetings, Sander.

@arg: I'd like to see this go mainstream; if you agree on that, I
suggest to resort the keys in kpress(), they are a bit messy now (I
didn't resort them in this pull request to keep the pull request less readable). And
by the way: the reason I implemented the XK_End behavior this way is
because it leaves the 'pages' intact. A simplistic
    while(sel->right)
        curr = sel = sel->right;
    calcoffsets();
Would probably do a similar job with slightly more overhead, but it
would change the beginnings and ends of pages. The way it is now,
pressing End will lead to the exact same result as keeping PageDown
(or -->) down for a while, which the above code would not do (in least
cases). Since that keeps things less predicspacele, I think it should be
the way it is in my pull request; besides, I checked the speed on my Pentium
2 (400 mHz), with a list of 10.000 items, and jumping from the start
to the end isn't noticably slower than jumping from the end to the
start (a _much_ cheaper operation) anyway.