[pmc] Clarify dead coroutines

Coros are not resumable when all yield states are exhausted.
This is consistent with the LUA design, which we follow, and all other
coro implementations I know of. Just the parrot book argues that after a
return the state should be automatically reset. Technically no problem, even
without the quirks described in https://github.com/parrot/parrot/issues/564#issuecomment-3503597
or via a seperate reset() method, but semantically an auto-reset is problematic.

Added testcases for all the relevant tickets: #564, #585 and there is on
bug remaining: TT #1003 leading to Null PMC access in get_string on a dead coro
[pmc] Coroutine is now auto-resetting
[pmc] Add Coroutine.reset() method

Mentioned in GH #564.

It is however more efficient to clone an initial coro and
copy this saved clone back, as the context does not need to
be recreated afresh.
coro: implemented autoreset method and attribute

fix crashes in sub_continuation_rewind_environment()
Still using traceflag 8. Maybe I should adopt it or resuse the SUB_CALL_FLAG?
core: autoreset tests, TRACE_CORO, PARROT_TRACE_CORO_STATE_FLAG

add TRACE_CORO define, -t8 only usable when not --optimizing
fix -t2 returning from coroutine msg.
-t2 msg either Coroutine autoreset or Coroutine no autoreset
add autoreset test, not yet working (one-off same as TT #1003)
Document -t8 flag, harmonize parrot usage messages

along parrot and parrot_old
Omit GH issue prefix from ChangeLog if default.
[cage] fix 2 codingstd issues with TRACE_CORO
[core] Disable -t trace flags 4+8 with --optimize

Fixes GH #1105
add to ChangeLog
[test] change closed TT #1003 ticket to new GH #1106