Use size_t to store heaps count

[alexandre-daubois]

After #19447 (comment)

I chose size_t over other alternatives because spl_heap_elem() already uses size_t for its index param, and heap's max size also uses this type.

[TimWolla]

This is just small-scale internal cleanup of non-exported stuff, thus not requesting RM approval.

[bukka]

@TimWolla I think you should be getting RM approval for any feature in beta by https://github.com/php/policies/blob/main/release-process.rst#beta-releases and RM should decide if it's small enough.

[bukka]

Thinking about it I think we should maybe rather update policy as it really doesn't make sense for those smaller features to require RM approval

[bukka]

But it's hard to say where draw the line because some huge refactorings should be probably considered as they might potentially introduce bugs and destabilize release.

[TimWolla]

@bukka I consider this one to be more of a bugfix than a feature. It does not affect the public API and fixes some type- and signedness-mismatches (passing int to size_t and comparing int to size_t).

If this would've affected a header file, I would've requested review.

[bukka]

That makes sense

[iluuu1994]

That document also doesn't clarify whether a change must be user-facing to be considered a feature. Or, if this is extended to internal code, whether it applies only to the API. IMO, it makes little sense to apply it to refactorings that don't change APIs, as those can always be reverted without any consequences to 3rd parties. Once we've branched master, it makes sense for new refactorings to go to the new master, so that we don't accidentally break things during the last testing phase(s) of the new release.