feat(kvp-client): add client asynchronous kvp natives

[outsider31000]

Goal of this PR

just like the server we add client asynchronous natives.
using async natives reduces the load on the client as it's not always needed to wait for the operations to finish

How is this PR achieving the goal

the goal is to have it stream lined with the server natives that already have async natives

This PR applies to the following area(s)

FiveM/RedM

Successfully tested on

Game builds: ..

Platforms: Windows, Linux
windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

[outsider31000]

@prikolium-cfx what you think how we should proceed ?
my changes would not be breaking scripts, I think everyone assumes the delete native on client is sync due to the name , when in the server is async and the docs is declared as shared with no mention of the client native being async despite the name.

So my question is:
Do we fix it with my changes (to correct it and avoid miss interpretation and keept it stream lined with the server) or leave it as it was ?
if you could give some advice on this would be appreciated.
thanks

[James-the-Coding-Gamer]

yeah I always thought the DeleteResourceKvp on the client was sync lol

[AvarianKnight]

It should also be noted changing this from being async -> sync will also have performance implications since the sync versions are notably slower, and people who used this not thinking it had any performance implications, will suddenly have to deal with the overhead of it being synchronous.

[outsider31000]

People who use this don't even know it's async in the first place, don't think a few ms per call would be more important to "keep" than correcting the mess and allow it to use it properly aligned with server natives and with no miss interpretations.

But that's just my opinion.