fixes

[DerThorsten]

• drain all messages instead of just one
• remove controller handling from xuv_runner since that only needs to handle the shell. the controll messages are handled via the xcontrol_default_runner (thats intended, isnt it @IsabelParedes ?)
• fix typo (XEUX_UV_API -> XEUS_UV_API )
• renamed header for consitency (xeus-uv.hpp -> xeus_uv.hpp)
• a critical missing #include "xeus-uv/xserver_uv.hpp" in "xeus-uv/xserver_uv.cpp". With that beeing missing, theXEUS_UV_API` visibility was not considered for that symbol which made that symbol hidden in the dll/so
• use macos14 instead of deprecated macos13:
  • this means we drop mac-intel because macos13 where the last intel based mac runners, now its all arm

Open questions / points:

• I am tempted to rename xhook_base to something more descriptive
• windows tests seem to pass even when there are headers missing and it cannot build => windows seems to always pass even when the build should fail...

[JohanMabille]

Remove controller handling from xuv_runner since that only needs to handle the shell. the controll messages are handled via the xcontrol_default_runner (thats intended, isnt it @IsabelParedes ?)

The "controller" here is not the control channel, it is the socket used for internal communication between the control and the shell channels (typically used for stopping the shell thread, or for sending code to execute to start the debugger). It must not be removed.

[DerThorsten]

Remove controller handling from xuv_runner since that only needs to handle the shell. the controll messages are handled via the xcontrol_default_runner (thats intended, isnt it @IsabelParedes ?)

The "controller" here is not the control channel, it is the socket used for internal communication between the control and the shell channels (typically used for stopping the shell thread, or for sending code to execute to start the debugger). It must not be removed.

Since the tests passed even without it, maybe we should extend the s.t. they would not pass without these handlers

[JohanMabille]

I would have expected the shutdown_request test fail.

[JohanMabille]

Why removing this?

[DerThorsten]

...overenthusiastic cleanup

[DerThorsten]

I would have expected the shutdown_request test fail.

but it was not failing...and restarting the kernel (ie python kernel) seemed to work just fine.
I did never see any message on the controll part of the runner, thats why I was removing it. So something seems to be odd there.

[JohanMabille]

Indeed that's weird. Anyway, we'll need it for the debugger.