Drop mimeType and ctime from the manifest format (closes #235)

Nothing goes in the 1.0 manifest that 1.0 does not read or write, and
mfer never wrote either field. mf.proto now reserves the numbers 301 and
303 and both names in MFFilePath, and mf.pb.go is regenerated. The
decoded-size check counts only file entries, hashes and timestamps,
export prints no ctime, and FileEntry loses the Ctime nothing set.
FORMAT.md and the README no longer describe either field.

The test of entries that decode too large gives each entry a second,
empty hash: an entry with one hash and a modification time can no
longer reach 8 times its size.

Model: opus-5-5

README.md

@@ -196,8 +196,7 @@ The manifest file would do several important things:
   a signature and a public key alongside in a single file
 - contain a list of files, each with a relative path to the manifest
 - contain manifest timestamp
-- contain ctime/mtime information for files so that file metadata can be
-  preserved
+- contain mtime information for files so that file metadata can be preserved
 - contain cryptographic checksums in several different algorithms for each file
     - probably encoded with multihash to indicate algo + hash
     - sha256 at the minimum
@@ -369,8 +368,8 @@ are now tracked only in the [issues](https://git.eeqj.de/sneak/mfer/issues).
     - (fetches `https://example.com/manifestdirectory/index.mf`, downloads and
       checksums all files, resumes any that exist locally already)
 - `mfer fetch https://example.com/manifestdirectory/`
-- a command line option to zero/omit mtime/ctime, as well as manifest timestamp,
-  and sort all directory listings so that manifest file generation is
+- a command line option to zero/omit mtime, as well as manifest timestamp, and
+  sort all directory listings so that manifest file generation is
   deterministic/reproducible
 - URL format
   `mfer fetch https://exmaple.com/manifestdirectory/?key=5539AD00DE4C42F3AFE11575052443F4DF2A55C2`