Interface abstraction hardening tracking issue

This is meant to be a tracking issue for the general discussion around establishing the interface contracts RAJA presents to users, and requires internally. @rhornung67, @keasler, @ajkunen, @davidbeckingsale, @DavidPoliakoff and myself have had a number of discussions on these topics, and I would be grateful for any clarifications or extensions you all would like to add on these topics. Not all of these things will necessarily be done, but they're things we've talked about enough that I think they deserve to at least be considered, and this will help us keep track of them.
- Define the interface elements required of:
- [x] Iterables:
- [x] Segments: PR #39 makes a first pass at this, allowing any random access iterable to be passed as an Iterable, this may be a first step
- [x] IndexSets (if different from segments)
- [ ] others: are forward iterators sufficient for sequential policies? This might be useful for implementing IndexSet style generators.
- [x] Execution policies
- [x] Backend implementations (like cilk/openmp/...)
- [ ] Clarify what is the job of the execution policy and what is the job of the iterable, these sometimes get conflated a bit and it may help for clarity of the interface to normalize it where possible.
- [x] Define what interfaces are user-facing and what interfaces are "internal." This is important for defining how things can be extended, and may allow us greater internal flexibility while maintaining user-facing API compatibility.
- [x] Explore the possibility of normalizing the interfaces used for forall and forallN policies (highly related to the required interface of an execution policy, but not necessarily the same)
- [ ] Investigate what will be required to support:
- [x] Plugins, such as CHAI, profiling etc.
- [ ] Asynchronous regions, including dependencies between them
- [ ] Generalized, and possibly more efficient, reductions (option note, if the lambda is copied by value into each thread or task context, this may have some nice and interesting possibilities)
- NOTE: the two above may be approachable as a common item, we've been calling one option for this a "context," somewhat in the style of CHAI's context mechanism but more generalized
- [ ] Wherever possible establish formal contracts for all of the above, in the style of those discussed in c interfaces and implementations or the flux RFC process, with what is an error checked at compile time, error checked at runtime, and what is an unchecked error. This is _hard_ and much more like working on a standard, but the more we keep it in mind the easier it would be to do later.

Start by reviewing the tracking list and PR #39, then read the discussions referenced in the issue about iterables, execution policies, backends, plugins, asynchronous regions, and reductions. This is done only when the remaining interface questions are resolved and formal contracts specify compile-time, runtime, and unchecked errors.

Written by the indexing model from the issue text.