Add ability to access an AggregateType's param and type fields [reviewed by hilde]

This patch adds the primitives PRIM_QUERY_TYPE_FIELD and PRIM_QUERY_PARAM_FIELD
to the compiler, enabling access to a given record or class type's param or
type fields from Chapel code.  For some class C defined as:

class C {
  param foo: <anytype>;
}

or 

class C {
  type foo;
}

the user can grab and re-use the contents of the field foo without calling a
getter on a specific instantiation of the class.  This is done by calling:

__primitive("query param field", t, "foo");

or

__primitive("query type field", t, "foo");

respectively, where t in this case is a generic instantiation of class C such
that the field foo has a value associated with it.

Summary of changes:
compiler/AST/primitive.cpp
compiler/include/primitive.h
compiler/main/checks.cpp
compiler/optimizations/optimizeOnClauses.cpp
  Add checks and basic presence of PRIM_QUERY_TYPE_FIELD and
  PRIM_QUERY_PARAM_FIELD

compiler/resolution/functionResolution.cpp
  Implementation of the primitives.  During function resolution, replace calls
  to these primitives with the substitution provided by the type instantiation
  if one exists.

test/classes/lydia/*.chpl
  Some tests of the functionality of these primitives.  Ensures they work in the
  basic case, a common source of error (called on non-AggregateType), and a
  future describing our ideal syntactic sugar for this functionality.

  Note the absence of a test where the user specifies a field that does not
  exist.  When looking through the compiler, I noticed a TODO in the getFields
  method to generate a user error in some cases rather than always an internal
  error.  Since this is the same situation, I figured a future was already in
  place and so have forgone a specialized error message for the time being.

tested over std/


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@23737 3a8e244f-b0f2-452b-bcba-4c88e055c3ca