Quiet align.chpl errors on Intel and PGI.

Changed align.chpl to better demonstrate the original intent.
Added a new future to demonstrate the compiler-dependent behavior.

I disagree with this comment ("Chapel should...").  I believe that in order to have a reasonable static type system, Chapel has to pick a single static type for +(int(32), int(32)) regardless of the values involved.  We can't generate different result types in different cases depending on the actual values being added because, in general, we can't know the values until runtime and our type system is static by design (for performance).  And I don't think we want to define a language in which we say +(int(32), int(32)) will generate a result of one type in the event that the compiler can reason about the values and thinks they're too big yet will generate a different type if it can't reason about them or doesn't think they're too big, because it makes things too dependent on how macho one's compiler is, and therefore unpredictable/non-portable.

We could make +(int(32), int(32)) always return an int(64), but we've already done something like that (made + on pairs of int(8)s and int(16)s return an int(32), and ended up deciding that it was way too much hassle if you wanted to work at a particular bit-width because of all the downcasting required to stay there.  Besides which, it suggests that int(64)+int(64) should return something even bigger, that int(64)*int(64) should return something even bigger than that, etc.  Instead, we chose to follow the simpler/more conventional thing and kept each operation closed on its type.  This doesn't seem like a big surprise to anyone using conventional performance-oriented languages.  And the BigInt/GMP types, as it they get mature, can give other users the infinite precision they might want.

We might be able to have max(int(32)) return a param int(64) instead of an int(32) in which case this would've done what you arguably wanted/expected.  I think the original implementer of max(t) thought it should return a value of type t which seems reasonable (and perhaps makes sense in a type inference setting), but seems to be part of the trouble here.  That could be a separate future/discussion, but I wouldn't let it hold up this fix.

So, personally, I'd prefer to see this note removed because it seems hard to defend.  And I also think it's not necessary if you take the proposed maxS1 definition above.