Update layout constraint explanation

[Anjiang-Wei]

No description provided.

[lightsighter]

I think this pull request is definitely fixing something that needs to be addressed, but I'm not sure it's accurately describing what is going on. There are actually two separate things we want to capture.

1. The mapper can control the layout of instances through the layout constraints. It can do this regardless of what constraints the task variant expects.
2. Task variants can register layout constraints for the instances that they assume to ensure that the variant is not used improperly.

These two things are related, but the mapper can make decisions in either order. Either it can pick layouts for all the instances and then try to find a task variant that works for those selected instances, or it can pick a variant and then try to make instances that match the expected layouts for that variant. Legion has no preferences on which direction the decision process flows. In general, most mappers seem to do the latter approach, but nothing says it has to go that way.

@Anjiang-Wei you're welcome to take a crack at this, or you can wait for me to get around to it. Either is fine.

Aside: the choice of using SOA vs AOS layout doesn't impact the ease of reuse of the instance. If all the mappers agreed on using AOS by default, then AOS would probably lead to more reuse.