Explain more on the difference of where constraints

[danakj]

This adds language to explain where the types of constraints can or can not appear (attached-to an impl-as vs in-a type expression). And describes the impact of using a rewrite vs same-type constraint inside the body of the affected code, and thus why a rewrite is preferable when the constraint is of a single facet type.

[josh11b]

We currently don't allow you to use the name of the binding inside the type of the binding, so this is written instead like:

Suggested change

	fn F[T: Interface where T.A impls OtherInterface](t: T) { ... }
	fn F[T: Interface where .A impls OtherInterface](t: T) { ... }

[josh11b]

I've been discussing this with @zygoloid , and we're ending up in a slightly different position. The right of an impl as declaration can have any where constraint. Rewrite constraints are the only thing that can assign values to associated constants. Other constraints are allowed, but would not normally be written. They can arise as part of using a named constraint, though, and when they do they have a meaning: if they are not satisfied by the impl declaration, a diagnostic will be issued. They don't otherwise enable anything in the impl, so it doesn't accomplish anything to write them.

Example of using a named constraint:

interface Container {
  let IteratorType:! Iterator;
}
constraint RandomContainer {
  extend Container where .IteratorType impls RandomAccessIterator;
}
// The following is equivalent to:
//    impl MyContainer as
//        (Container where .IteratorType impls RandomAccessIterator)
//        where .IteratorType = MyIteratorType
// This checks at compile time that `MyIteratorType impls RandomAccessIterator`,
// but is otherwise equivalent to:
//    impl MyContainer as Container where .IteratorType = MyIteratorType
impl MyContainer as RandomContainer where .IteratorType = MyIteratorType {
  // ...
}

[danakj]

Do you think it would be fair to describe the named constraint case as a separate 3rd position, as it has different meaning there? Or is it important to note here that you could write that type of constraint on a class impl-as as well?

[josh11b]

The design intent is that the language avoids distinguishing any kind of facet type from any other. This both simplifies the language and allows some evolution transitions to occur in a compatible way.

[josh11b]

Maybe say "It would normally only be used in the type expression position." here and below?