py/objgenerator.c: Allow pend_throw to an unstarted generator. - #5275

I just tested the behaviour and can confirm that it works as expected. Thanks.

Updated tests to catch the missing coverage.

Overall code-size change for this PR is:

   bare-arm:   -24 -0.036% 
minimal x86:   -12 -0.008% 
   unix x64:   -48 -0.010% 
unix nanbox:    -8 -0.002% 
      stm32:   -20 -0.006% PYBV10
     cc3200:   -32 -0.017% 
    esp8266:   -44 -0.007% GENERIC
      esp32:   -32 -0.003% GENERIC[incl -32(data)]
        nrf:   +24 +0.016% pca10040
       samd:   -32 -0.031% ADAFRUIT_ITSYBITSY_M4_EXPRESS

So, independently of whether this is eventually useful for uasyncio, I'd say it's a good change because 1) it generalises a feature; 2) it reduces code size.

A quick question to your PR:
I saw an attribute "pend_exc" that was "is_running" before but the purpose is not entirely clear to me: Does it indicate the generators general status? Like will it be running until it is fully cancelled or does it only indicate that the generator is currently executing some code until it yields?

If it indicates the general status of a generator, could it be used to implement the CPython equivalent of "task.done()" returning if the generator is finished executing code?
This way we would be able to check if a generator is fully canceled/finished without having a task implementation.
If that is not the case and the attribute is used differently, you don't need to explain it, my understanding is not important in this case :D I just thought about "coro.done()" when I saw it.

I saw an attribute "pend_exc" that was "is_running" before but the purpose is not entirely clear to me: Does it indicate the generators general status? Like will it be running until it is fully cancelled or does it only indicate that the generator is currently executing some code until it yields?

It's the latter. i.e. the generator is currently executing code up to the next yield. This really only exists to prevent trying to call next/send/throw (or pend_throw) on itself. (See the test case I added that shows this in action).

If it indicates the general status of a generator, could it be used to implement the CPython equivalent of "task.done()" returning if the generator is finished executing code?
This way we would be able to check if a generator is fully canceled/finished without having a task implementation.

Yeah, unfortunately it doesn't, but it could actually be easily extended to do so with another sentinel value (this is actually what I had in my mind when I wrote "another extension to objgenerator.c to interrogate a generator instance and find out whether it has finished" on #5242

With the latest changes/fixes to this PR the code-size change is:

   bare-arm:   -48 -0.072% 
minimal x86:   -60 -0.040% 
   unix x64:   -80 -0.016% 
unix nanbox:   -40 -0.009% 
      stm32:   -36 -0.010% PYBV10
     cc3200:   -40 -0.022% 
    esp8266:   -60 -0.009% GENERIC
      esp32:   -64 -0.005% GENERIC[incl -48(data)]
        nrf:   -36 -0.025% pca10040
       samd:   -48 -0.047% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Merged in 576ed89 and 5578182