fix(utilities): ensure consistent typing for objectEntries, objectKeys and objectValues

[GeniusTimo]

I noticed that these functions have return types that do not match the type assertions within their implementations. After reviewing the pull requests that introduced these functions, I believe the idea to use ArrayLike<infer Values> (see #474 (comment)) may have unintentionally caused some confusion. The idea for the objectValues function was only implemented to the type assertion within the function and not yet for its return type (de87080 ✔)

To improve consistency, the same idea was adapted for the objectEntries function (see #471 (comment)). However, it was implemented as if Object.entries returned the values, not the entries, when dealing with array-like objects (9d6d3e8 ✔)
Because the return type of the function was not updated to reflect this change, it had no real impact. To align with the intended consistency, I have updated the return type to match the corrected type assertion (34c3205 ✔)

The type of the values within an array-like object is not relevant to the objectKeys function. However, the idea was also applied to that type assertion (see #472 (comment)) Because the return type was not adjusted accordingly, this change also had no actual effect. I have fixed this as well (b43fba0 ✔)

This pull request is meant to reduce potential confusion for future contributors. The details regarding the previous implementation are provided for traceability only and are not intended as criticism of or offense to anyone involved back then.

[favna]

Could you add unit tests for this using vitest testing types? To ensure that the same mistake is not made in the future because these types are quite complex.

[GeniusTimo]

I'm not familiar with vitest yet, but I've tried my best. Since we can't test the type assertion within the function (at least to my knowledge), I feel like checking the return type for arrays is all we can add?