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.

Adjust a symbol name to match the language of the new doc string.

Include the string "mailaprop" in the minibuffer messages shown while
`mailaprop-load-addresses' is loading the addresses and building the
cache.  That way if it takes a long time, the culprit will be clear.

The documentation tells the user to initialize `mailaprop-addresses'
themselves.  Therefore, mailaprop.el should not do it at load time,
because if it were to do so, then `mailaprop-address-file' would need
to be set by the user before mailaprop.el were loaded, and it is not
good to have an unexpected ordering dependency like that.