Revert "autofill: recognize "login" as a login box"

This reverts commit 9636e3cab3921f9ab243a8aa404da04a4097b73d.

That commit improved matching on some sites, but makes other
sites much worse (e.g., ones that have "Login$Username",
"Login$Submit", and so on). So clearly we need smarter
heuristics. It may be enough to just set the first such
element we see.

Unfortunately, I don't recall the exact site which prompted
9636e3cab in the first place, so I don't have data with
which to make a heuristic. Let's back it out for now, and we
can replace it with a better rule when the problem
reappears.
autofill dynamically from perl script

The original idea behind --generate-autofill is that we
would generate host-matches via regex, so that we could know
which candidates we have for auto-filling even before
opening the password file. The advantage being that we would
not ask to unlock the file only to discover there was
nothing interesting.

However, since the pentadactyl side of the autofill does not
run automatically, but rather only when the user requests
it, this isn't much of an advantage. The user doesn't bother
triggering it unless they expect there to be a fillable
item.

Therefore we can push the filling logic down into the perl
script without any significant loss, and several advantages:

  1. You no longer have to pre-generate the autofill
     javascript when the set of autofills changes.

  2. The quoted regexes were ugly and hard to debug.

  3. Better privacy; the set of regexes is not in cleartext
     on the disk any more.

There is one case it does not handle as well: we used to
accept a regex as a "fillurl", which meant that a given
entry could match multiple sites. It would be possible to
support this by allowing multiple "url" fields for each
element, but this patch does not do that yet.