doc/ref/spec: consider definitions for closedness

Definitions were excempted from closedness checks.

With this change, it can be guaranteed that if a template
writer does not make an existing field more specific
and a user doesn't embed the template, the changes
cannot break a user.

Consider this template:
	-- pkg.com/foo/foo.cue --
	#Def: {}

And its usage:

	-- bar.cue --
	import "pkg.com/foo/foo.cue"

	def: #Def & {
	  #foo: 2
	}

The introduction of #foo is currently allowed, as
closedness is not checked for definitions. So
if the original template is no augmented as such

	-- pkg.com/foo/foo.cue --
	#Def: {
	  #foo: 1
	}

it breaks the user.

This means though, that it breaks the property that if
a template writer changes their template, it may
conflict with a definition that a user may have added.

This already holds for regular fields, but that is to be
expected. Users can still add definitions by embedding
the struct. But the same warning applies in this case
for regular fields and definitions, making it more
consistent.

Breakage can also occur if a template writer makes a
template more specific. Again here also, this also holds
for regular fields and this also makes definitions more
consistent with regular fields.

Change-Id: I1e2aedcf6cc4b17f17f9b4a742ca7aac238ae382
Reviewed-on: https://cue-review.googlesource.com/c/cue/+/6721
Reviewed-by: Marcel van Lohuizen <[email protected]>

Author: mpvl

doc/ref/spec.md

@@ -1234,9 +1234,10 @@ A1: A & {
 //    { field1: "foo", field2: string }
 ```
 
-A _closed struct_ `c` is a struct whose instances may not have regular fields
-with a name that does not match the name of a regular or optional field
+A _closed struct_ `c` is a struct whose instances may not declare any field
+with a name that does not match the name of a regular or optional field,
 or the pattern of a pattern constraint defined in `c`.
+Hidden fields are excluded from this limitation.
 A struct that is the result of unifying any struct with a [`...`](#Structs)
 declaration is defined for all fields.
 Recursively closing a struct is equivalent to adding `..._|_` to its its root