[4638] Cleanup of plurals and inheritance relationships in AST

Changed the grammar so that the following "plural" constructs always
parse as an ASTArray:

- funcvalues
- rvalues
- resourceinstances
- anyparams
- params
- caseopts
- casevalues

And the following "singluar" construct never parses as an ASTArray:

- statement

The previous behavior was for these constructs to parse as a scalar
when they represented a single item and an ASTArray when they
contained zero or multiple items.  ("Statement" could sometimes
represent a single item because a single resource declaration could
represent multiple resources).  This complicated other grammar rules
and caused ambiguous handling of nested arrays.

Also made these changes to the AST class hierarchy:

- ResourceInstance no longer derives from ASTArray.  This relationship
  was not meaningful because a ResourceInstance is a (title,
  parameters) pair, not an array, and it produced complications when
  we wanted to represent an array of ResourceInstance objects.

- Resource no longer derives from ResourceReference.  No significant
  functionality was being inherited and the relationship doesn't make
  sense in an AST context.

- ResourceOverride no longer derives from Resource.  No significant
  functionality was being inherited and the relationship doesn't make
  sense in an AST context.

- Resource can now represent a compound resource instance such as
  "notify { foo: ; bar: }".  This saves the parser from having to
  use represent a statement as an array of objects.

- ASTArray's evaluate method never flattens out arrays of arrays.

0 files changed, 0 insertions, 0 deletions