Regent: how to expose "leaf context"

[elliottslaughter]

Currently Regent assumes that anything that uses __context() is not a valid leaf task, because in general __context() is required to access C APIs used for launching tasks. However, there are a variety of APIs that are valid in leaf tasks that still require a __context(), and all of these are currently disallowed in Regent leaf tasks. In some cases these might be very useful, e.g. Runtime::get_executing_processor().

I can see a couple ways to get around this:

1. Expect users to hack around it, e.g. by exposing Runtime::get_context() and using that inside a Terra function where Regent can't see it.
2. Add a separate form of context e.g. __leaf_context() (subject to bikeshedding) that is identical to __context() but does not trigger a failure in the leaf optimization checker. It will be up to the user to use it responsibly.
3. Expose all leaf-task-valid runtime APIs in a "context-less" form so that Regent doesn't need to change. (We've done this to an extent with the region tree traversal methods.)

Thoughts?

[lightsighter]

I'm planning to add an LEGION_IMPLICIT_CONTEXT macro that C/C++ users can pass to methods that require a context argument. The runtime actually knows the right context to use right now with it's thread-local variables, so there's no need to pass the context around explicitly anymore. This will also avoid us having to split the whole Legion API into "context" and "context-free" parts which we did start to do with region tree traversals, but I don't want to do that everywhere. Regent should then be able to expose context-free versions of the functions to users if it wants to.