Fix backup of folders with escaped characters in their name

[ashundefined]

Summary

Fix a backup failure for folders whose names contain a character that is
escaped on disk (for example :).

Problem

Serializer::Files escapes reserved characters when it builds file paths
for a folder (for example : becomes %3a;). When the delay_metadata
download strategy is used, DelayedMetadataSerializer built its own Imap
and Mbox objects directly from the unescaped folder path, bypassing this
escaping.

As a result, the two halves of a backup used different files:

• apply_uid_validity wrote the UID validity to the escaped path.
• commit read and wrote the unescaped path.

The UID validity was therefore not found when saving the metadata, and the
backup failed with: "Cannot save metadata without a uid_validity"

A second issue affected reading backups: when restoring, migrating, or
listing local folders, the escaped on-disk name was used as-is instead of
being decoded. A folder backed up as foo%3a;bar was treated as a folder
literally named foo%3a;bar.

Changes

• DelayedMetadataSerializer now uses the serializer's imap and mbox
  objects, so it reads and writes the same escaped paths as the rest of the
  serializer.
• Added imap and mbox delegators to Serializer.
• Account::SerializedFolders and Account::FolderMapper now decode
  escaped folder names with Naming.from_local_path when reading a backup.

Compatibility

The on-disk format is unchanged. Existing backups are unaffected; the read
path now decodes names that were already being written escaped.

Tests

• DelayedMetadataSerializer spec: verifies it uses the serializer's
  imap/mbox.
• SerializedFolders and FolderMapper specs: verify escaped on-disk names
  are decoded when read.