Streamline the conventions used for various APIs (which are currently fairly inconsistent)

[rdw-software]

See https://evo-lua.github.io/docs/references/code-conventions for an example of the complexity this brings (very unintuitive)...

There are multiple layers of abstraction that might warrant different conventions. But there's also a lot of "winging it", third-party libraries doing their own thing, and at least two or so ways of error handling used (failure returns, errors, and possibly others).

All in all, it's a bit messy and I've always been bothered by having to accomodate snake_case, PascalCase, and camelCase.

Before an organized cleanup can take place, however, a few common denominators need to be found that work for all layers:

• Error handling: C++ exceptions (bad/slow), failure returns (idiomatic), errors (easier to test/intuitive)
• Capitalization rules: C uses snake_case, C++ a mix of snake_case for C APIs, Pascal and even camelCase, Lua all three...
• Event handling: Callbacks are unavoidable with libuv, and event queues are unavoidable in the FFI - but Re-add the event system library so that events can be monitored (for testing purposes) #55 might wrap them all?
• Asynchronous I/O: Related to events, but it might make sense to also explore coroutines more (if they get better observability, see Improve the observability of coroutines (by adding events for state changes?) #316 )

TBD: What other issues and inconsistencies are there? Should review the entire codebase and jot down all potential issues here.

Potential inconsistencies in the Lua portions of the codebase:

• The vfs library is also referred to as LUAZIP (which is the signature header) and zipApp (Python lingo)

[rdw-software]

May also want to consider some of the points mentioned here: https://google.github.io/styleguide/cppguide.html

Not everything applies, but having a more consistent guideline than what currently exists would certainly help.