config-linux: Require no cgroup tweaks when linux.resources is unset

Or empty.  Using:

  "resources": {}

should mean the same thing as:

  "resources": null

or as not specifying 'resources' at all, so we can drop th "Do not
specify" requirement.

It's good to be clear about what leaving the properties unset/empty
means though.  I'd prefer a config-wide rule like [1], but if that is
too much to bite off I expect we can at least do that for cases where
a new container is joining an existing cgroup.

[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A
     Subject: Exposing platform defaults
     Date: Thu, 14 Jan 2016 15:36:26 -0800
     Message-ID: <20160114233625.GN6362@odin.tremily.us>

Signed-off-by: W. Trevor King <wking@tremily.us>

Author: wking

config-linux.md

@@ -172,9 +172,9 @@ The Spec does not include naming schema for cgroups.
 The Spec does not support per-controller paths for the reasons discussed in the [cgroupv2 documentation][cgroup-v2].
 The cgroups will be created if they don't exist.
 
-You can configure a container's cgroups via the `resources` field of the Linux configuration.
-Do not specify `resources` unless limits have to be updated.
-For example, to run a new process in an existing container without updating limits, `resources` need not be specified.
+You can configure a container's cgroups via the OPTIONAL `resources` property.
+When `resources` is empty or unset, the runtime MUST NOT alter properties of existing cgroups.
+When a subset of `resources` is empty or unset, the runtime MUST not alter the properties of existing cgroups covered by that subset.
 
 A runtime MUST at least use the minimum set of cgroup controllers required to fulfill the `resources` settings.
 However, a runtime MAY attach the container process to additional cgroup controllers supported by the system.