Add optional count argument to Semaphore::post

[RadiantUwU]

Implements a new optional argument in Semaphore.post to allow resuming multiple threads at once.

[Mickeon]

May I ask in what occasion would this be useful? It is a relatively innocent change, but it's still worth knowing why it would need to be done.

[RadiantUwU]

It's just so you dont have to do a for loop anymore to resume more and more threads, and it would be way more optimized than constantly locking and unlocking the mutex, adding 1 to the count and running notify_one.

[RandomShaper]

Leaving my approval on the added API. This needs to have the compatibility stuff fixed (which I'm not very familiar with) fixed per @AThousandShips comments before merging.

[Bromeon]

Was a named method considered (post_n or something)? Not sure what's the usual API design in such cases.

[Mickeon]

Is count as the name of the parameter completely fine? Yyyyeah, I'm sure it'll be fine.

[AThousandShips]

The co-author additions for just reviews aren't necessary by the way, feel free to remove them

[Mickeon]

I think we can safely push this to 4.4 . Still waiting on the GDExtension and DotNet teams for review.

[akien-mga]

Thanks!

[RandomShaper]

I've found something a bit concerning... One of my PRs was tested against 4.3, where it worked. On master it broke. The reason was that on master I had to add .bind(1) to a Callable to core_bind::Semaphore::post(); otherwise, I would get too-few-args error. On 4.3, adding the .bind(1) makes the code fail with too-many-args error. Therefore, there's a compat breakage here. Or is the reason that we have an issue with the binding-call system not honoring the default arg in case the .bind(1) is missing?

[AThousandShips]

The callable_mp system doesn't know anything about bound methods so it can't honor the default argument, and in c++ default arguments are a kind of decoration and won't actually be relevant to the method pointer itself, so it's not trivial to handle that without somehow utilizing the method bind system

[AThousandShips]

It's been discussed (forget where) and I've looked at some tricks to make it easier by creating a custom callable from a MethodBind but haven't done much on it as it's a bit convoluted, and would require fetching the method (also wouldn't work with non-bound methods, though we could use the bind without using the ClassDB system)

But will see about opening some issue to track it and look at ideas when I can

[Mickeon]

If this is a severe problem reverting this PR should be fine as it's a relatively small Quality-of-Life feature.