serialization: Require 'layers' for rootfs.type

I'd rather drop the field [1], but have been unable to convince
Stephen that there would not be side effects of that approach.  So
we're back to my initial recommendation that we require the 'layers'
value [2] and require implementations to error out if they see an
unknown value [3].

The use of "unknown" vs. "another" allows image and implementation
authors to collaborate on additional layer types if they see a need to
do so while ensuring that users not party to such extensions don't get
silently-broken behavior.  This relies on extention types being
suitably namespaced/unique so that two separate extension groups don't
pick the same type string, but that seems like a reasonably safe bet.

The spec does not provide any way to version this field, so users
wondering "is my tooling modern enough to handle this image and any
rootfs.type extensions it may contain?" should ask their tooling to
validate the image.

[1]: #224
     Subject: serialization: Drop rootfs.type (which had only one
       legal value)
[2]: #211 (comment)
     Subject: serialization: remove windows-specific layers+base rootfs
[3]: #211 (comment)

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

serialization.md

@@ -300,7 +300,8 @@ Note: whitespace has been added to this example for clarity. Whitespace is OPTIO
 
         <ul>
           <li>
-            <code>type</code> is usually set to <code>layers</code>.
+            <code>type</code> which MUST be set to <code>layers</code>.
+            Implementations MUST generate an error if they encounter a unknown value while verifying or unpacking an image.
           </li>
           <li>
             <code>diff_ids</code> is an array of layer content hashes (<code>DiffIDs</code>), in order from bottom-most to top-most.