Fix record in record bug

This patch provides a workaround for the "record-in-record bug" demonstrated by 6 futures in the users/ferguson/nested directory.  The tests were failing due to a mismatch between internally-generated constructor calls and the signature of the constructor for a nested record type.  Constructors for top-level record types are "free" functions, while those for nested record types are methods.  

The fix was to special-case calls to nested record constructors and make them look like method calls.  This resolves the problem, and causes those test cases to exhibit the expected behavior.  The corresponding .future files were removed.

This patch is considered a workaround because the signature of the nested record's constructor was left inconsistent with the constructor signature for top-level record declarations. On the other hand, the long-term intention is to convert all constructors back to methods, so using the nested constructors as-is could be considered to be strictly correct.



At this point, _defaultOf() for nested record (and presumably class) types uses the same syntax as for top-level record (and class) types.  However, the spec says that a nested class or record type is only visible within the scope of the outer class.  Other spec language implies that instances of nested classes and records are dynamically bound to the outer instance.

So, for example, you cannot say:
  _defaultOf(R.R2);
where R2 is a record nested inside R.  However, it should be perfectly legal to say:
  proc _defaultOf(type t) where t == R2 { ... }
inside the declaration of record R.