Expose state/functionality in `ParameterizeScope`, instead of just from configuration handlers

[BenWoodworth]

Currently, some of parameterize's functionality is only available from within the configuration hooks, which is very restrictive. All the functionality available with the configuration could be exposed, allowing it to be extensible and used more flexibly.

To avoid namespace pollution in the parameterize {} block, this functionality should be hidden behind a property in the scope. For example, inspired by coroutineContext in the stdlib, this could look something like parameterizeContext.isFirstIteration.

• decorator
  • isFirstIteration
  • isLastIteration
    • In decorator, this currently throws if accessed before the iteration() lambda is called. That can't be matched if generalized to use in the block, because the runtime can't know when the "iteration" code is done
    • Instead, maybe allow this to be read at any time, with the caveat that defining a new parameter could invalidate the previous result and change this to false
• onFailure
  • iterationCount
    • Already possible to track without using the API
  • failureCount
    • Already possible to track without using the API
    • Makes assumptions about what counts as a failure
  • arguments
    • Instead, as a list of ParameterDelegates, with property and argument
    • Named declaredcParameters (and maybe also renaming ParameterDelegate to DeclaredParameter)
  • breakEarly
    • Can be accomplished with non-local returns
  • recordFailure
    • Expose ParameterizeFailure so devs can keep track of them on their own
• onComplete
  • iterationCount
  • failureCount
  • completedEarly
  • recordedFailures
  • ParameterizeFailedError constructor