[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.