SpamAssassin is clearly not intended for use by mail clients, as
evidenced by the number of backflips Evolution's SA module still has to
do just to detect the presence and nature of a running spamd (a problem
which D-Bus solved a decade ago), and recent SA developer comments.

In lieu of removing SA support entirely, remove all the crazy GSettings
that are (thankfully) not exposed in the UI and relegate Evolution's SA
integration to only the most basic usage (spamassassin / sa-learn).

Users are better off with Bogofilter anyway.  Leave SpamAssassin for
mail servers.

Hidden setting, no clear use case, and poorly implemented.

This was added as part of bug 360184 but no justification was given
for the "local-only" part.  My Spidey sense tells me it was a hack-
around for the old implementation's tendency to freeze the UI while
searching for a photograph.  So the "local-only" option really just
meant "don't freeze the UI for very long, please".

The new EPhotoCache-based implementation in 3.8 NEVER freezes the UI,
so the "local-only" option is no longer needed.  If a remote address
book is slow or unresponsive we simply cancel the async photo lookup
when the user moves on to another email.

Replaces "paned-view-headers-state", which was defined as an integer for
some stupid reason.  Not bothering to migrate the old setting since it's
one button click.

The GSettings key was removed in commit f4c30fe:
"Bug #672249 - Crash when showing message with large text/plain"

This was causing gsettings-data-convert to abort and not mark itself
as having run, so the GConf conversion runs repeatedly, potentially
overwriting changes the user made in GSettings.

AFAICT, this key does nothing useful and only confuses me every time I
read the EShell migration code.

The "version" key records the most recently used Evolution version.
That's all we need for migration.  And since downgrading Evolution is
not supported, we can assume this value will only increase over time.