README: Update links after layer.md split

71650f2 (spec: split serialization into image and layer, 2016-08-24,
#206) pulled layer.md out of serialization.md, but did not update
these links.

I preferred the more generic "filesystem serialization" wording from
before, because while README readers should understand that we're
serializing the filesystem, they don't need to care about *how* the
filesystem is serialized.  Folks who do care about the serialization
should be reading layer.md.  But Brandon and Jonathan both liked the
"filesystem layers" wording [1], so that's what we have here.

While touching the paragraph, reformat to one sentence per line as
requested by the "Markdown style" section in the README.

[1]: https://github.com/opencontainers/image-spec/pull/285/files/05370b480e45a790dd86a8e3104e78fe802a786c#r78313284

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

Author: wking

README.md

@@ -2,7 +2,10 @@
 
 The OCI Image Format project creates and maintains the software shipping container image format spec (OCI Image Format). The goal of this specification is to enable the creation of interoperable tools for building, transporting, and preparing a container image to run.
 
-This specification defines how to create an OCI Image, which will generally be done by a build system, and output an [image manifest](manifest.md), a [filesystem serialization](serialization.md), and an [image configuration](serialization.md#image-json-description). At a high level the image manifest contains metadata about the contents and dependencies of the image including the content-addressable identity of one or more filesystem serialization archives that will be unpacked to make up the final runnable filesystem. The image configuration includes information such as application arguments, environments, etc. The combination of the image manifest, image configuration, and one or more filesystem serializations is called the "OCI Image".
+This specification defines how to create an OCI Image, which will generally be done by a build system, and output an [image manifest](manifest.md), a set of [filesystem layers](layer.md), and an [image configuration](serialization.md).
+At a high level the image manifest contains metadata about the contents and dependencies of the image including the content-addressable identity of one or more filesystem serialization archives that will be unpacked to make up the final runnable filesystem.
+The image configuration includes information such as application arguments, environments, etc.
+The combination of the image manifest, image configuration, and one or more filesystem serializations is called the "OCI Image".
 
 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
 
@@ -18,7 +21,7 @@ The [Media Types](media-types.md) document is a starting point to understanding
 
 The high level components of the spec include:
 
-* An [image manifest](manifest.md) and [filesystem serialization](serialization.md) (base layer)
+* An [image manifest](manifest.md), a set of [filesystem layers](layer.md), and [image configuration](serialization.md) (base layer)
 * A process of hashing the image format for integrity and content-addressing (base layer)
 * Signatures that are based on signing image content address (optional layer)
 * Naming that is federated based on DNS and can be delegated (optional layer)