This was always my intent; I'd just typo'd the `case-fold-search' binding.

Also make a minor clarification later about interactive speed.

This is easier for me to remember and avoids a completion collision.

We now handle the following exceptions when parsing headers:

  * "UnicodeEncodeError: 'utf-8' codec can't encode character '\udcf8'
    in position 64: surrogates not allowed (also from absorb_headers()"

  * "email.errors.HeaderParseError: expected ':' at end of group
    display name but found '@GMAIL.COM"

    (which would then lead to "TypeError: 'ValueTerminal' object does
    not support item assignment")

  * "ValueError: hour must be in 0..23" (from bogus Date headers)

Also:

  * Solve a newly-discovered quoting problem in the output

  * Ingest 'reply-to' as an address-containing header.

This is part of issue #1.

This is part of issue #1.

This follows up to commit ce519dab.

This solves the backslash-in-names problem.

When reloading addresses, if there was already a buffer visiting the
`mailaprop-address-file' (rare, but can happen e.g. when one is
debugging mailaprop) then don't kill that buffer when done reloading.

This input data produces problematic output like this:

  "Firstname2\ \\"Lastname2 <second_recipient@receivers.example.com>"

Not sure yet whether the fix should be in mailaprop or just in
filtering the input, but anyway we need a reproduction case.

Add interactive functions `mailaprop-complete' and `mailaprop-matches'
and helper function `mailaprop-display-something-maybe-big'.

(Unrelated to commit 17cdfc95, surface similarity notwithstanding.)

Rename `mailaprop-memoize-dict' to `mailaprop-candidate-cache'.

What `mailaprop-load-addresses' is building is the address data
proper, not a cache.  Adjust the user-visible message accordingly.