Charm++

We've fixed zero-argument entry methods to accept CkEntryOptions at the call site, and to respect group construction dependences, so their semantics are at least strictly correct. We're just missing priority/queueing stategy now, which is part of the performance semantics, but not the program correctness.

It's clear why it's implemented this way - the code on both send and receive sides would have to be duplicated to choose between working with a zero-payload system message and a dynamically allocated message with room for a priority or whatever else the options might dictate. Nevertheless, it's a somewhat glaring and surprising inconsistency that some entry methods can be passed options, and others can't.