Unify corerun's implementation of the native debugger check with the minipal for all platforms

[jkoritzinsky]

Deduplicate the non-Windows path so new platforms only need to add support in one place.

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[am11]

Looks like an always-true condition?

[jkoritzinsky]

It’s true for every platform we support, but if you build on an unsupported platform, we’ll hit the false case.

[am11]

IMO, just delete minipal_can_check_for_native_debugger and add #else\n#error "Not yet implemented" on line 47 to let the person/team consciously make a determination during the porting time (whether they want to ignore this feature by adding #elif defined(__someOS__) /* ignored */ or implement it as part of the port).

[AaronRobinsonMSFT]

@am11 I agree with these thoughts for most features, but the debugging scenario seems different. It doesn't need to exist for new platforms and not having a very basic "debugger supported check" means we then may need to add additional compile time checks in other places, which I think we'd like to avoid. The pattern here seems to be very simple, even if clunky, so new platform bring up can focus on "Hello, World" or just ignore debugging if desired.

Am I missing some mechanic of your proposal that would make this easier?

[am11]

@AaronRobinsonMSFT, without the additional API: main...am11:runtime:dedup-debugger-check, it wouldn't block HelloWorld during the port to new platform. To get by, the person will add an empty elif branch likely with a TODO (as they would need to adjust tons of other places) and obviously not use -d or --debug options with corerun, as wait_for_debugger is only called in that case.

No big deal, but that build-time error is the more prevalent pattern used in coreclr (I remembered hitting them in past adventures 😅).

[jkoritzinsky]

/ba-g debugger helix workitem deadletter (which we can't use known issues for today)