AbtractModelLoader: Marry-up Class attributes and parameters
Add a test for named invocation with a method reference argument
Fix problem with named invocation with a method reference argument
AbstractTransformer: Make some comments JavaDoc for easy viewing in Eclipse
Issue #941: StatementTransformer: transformIterableIteration(): Factor out a method for generating a 'for' iteration over a Ceylon Iterable, which we can use for the Celyon 'for' statement and also []. (SpreadOp)
StatementTransformer: Tidy up some local variable names after addition of transformIterableIteration()
Issue #941: Change how we transform a []. (SpreadOp) to use a SequenceBuilder
Issue #941: Tidy the SpreadOp test
Issue #941: Fix .src changed by the revised SpreadOp transformation
ExpressionTransformer: Move some methods from Invocation to ExpressionTransformer
call ProducedType.resolveAliases a lot more now that the frontend requires us to
Fixed some tests .src due to more canonicalisations thanks to more calls to ProducedType.resolveAliases()

That undoes the opposite modifications that I did recently to those .src, I was wondering what changed,
it was that the frontend did less canonicalisations, which we now restored
Marked test for #816 as failing
Issue #929: Move the tests out of IssuesTest: There are a number of cases to
test so lets avoid cluttering the issues/ subtree.
Partially fix #929 by:

* Allowing the 'declaration' of transformations which push an uninitialized
  reference onto the operand stack,
  ( see ExpressionTransformer.uninitializedOperand(boolean) )
* Allowing the 'declaration' transformations which use a backward
  branching construct
  ( see ExpressionTransformer.backwardBranch(Node) ),
* Changing the transformed 'new' expression to use a LetExpr
  when both of these conditions hold (essentially as described by Stef in the
  discussion on #929), see CallBuilder.evaluateArgumentsFirst(boolean) and
  it's callers. This handles the cases of a SequenceEnumeration (i.e. an
  implicit instantiation of ArraySequence) and an
  explicit instantiation with a spread op (implicit 'for' loop)
* Changing the transformation of 'super()' invocations when
  a backward branch is used in the transformation of the arguments to the
  'super()' invocation. In this case we generate static methods to hold
  the argument expressions thus the backward branching construct operated in a
  method without an uninitialized reference implicitly on the operand stack
  (as is the case with the invokespecial of an <init> method).
* Because we're using static methods to contain the super() invocation's
  argument expressions this doesn't work for inner or local classes with a
  spread in their superclass initializer invocation. At the moment we
  makeErroneous() in such cases. I hope to address this hole at some point.
Shortened the list of exceptions for the compileRuntime test (the ones removed don't actually work, but they do compile, which is the only thing that test is good for anyway)