Fix annotations for docs parser

[DapperDino]

• Updated casing/variable names to have annotations match code for the parser.
• Added missing annotations found along the way
• Left some as they were, even though they are causing parser warnings. The parser should be updated to deal with edge cases in the future (for lua and typescript)

[sesposito]

@DapperDino My only concern is that there's a lot of places where matching the variable assignment name to the annotation to clear the warning makes it less "readable" or introduces the type in a redundant way (e.g.: fooIn, fooString, etc). I stopped reporting them in the review. I'll leave it to you to decide if they should be changed or not. I understand that matching the implementation is very tedious and error-prone. Maybe we should prioritize improving the annotation parser instead of going down this route, but I'll leave it to the @heroiclabs/devrel team to decide.

[DapperDino]

@DapperDino My only concern is that there's a lot of places where matching the variable assignment name to the annotation to clear the warning makes it less "readable" or introduces the type in a redundant way (e.g.: fooIn, fooString, etc). I stopped reporting them in the review. I'll leave it to you to decide if they should be changed or not. I understand that matching the implementation is very tedious and error-prone. Maybe we should prioritize improving the annotation parser instead of going down this route, but I'll leave it to the @heroiclabs/devrel team to decide.

For now I was trying to get them all matching, then the decision can be made whether we want the annotations to be shorter in the cases such as userIDString vs userID. Ideally I would want the annotations to take the shorter naming, or whichever is most readable on a case by case basis, but if the parser was to ignore the actual variable names, then that's how we end up having missing parameters in the docs. This change isn't urgent so there's no rush to get this merged in. I'm happy to make more modifications before we finalize it.

If we then based the variable names in the functions always off the annotations, then that would work, but would that mean the annotations would driving the code too much? I guess not as if we name the variables to be easily readable, it shouldn't be a problem to use that name in the code itself, as it should be named well.

[sesposito]

Left a minor comment, but otherwise 🏆

[sesposito]

Perhaps body is more suitable here? (and for the other runtimes too).