Allow custom checks before allowing a player to protect new areas

[a-tour-ist]

Implements #53, using the return values proposed there.
I removed the hardcoded restrictions in areas:canPlayerAddArea and re-registered them with the new api call.
This makes it possible to overwrite all conditions for modders and, more importantly, ensures that the error message from the first callback which failed is returned.

[a-tour-ist]

My local luacheck runs fine with this, I would appreciate a hint on what I am doing wrong...

[Niklp09]

I would appreciate a hint on what I am doing wrong...

I had to manually approve the luacheck run for this PR since you're a first time contributor to this repo.
Code lgtm, good idea to add an API function for this.

[SmallJoker]

This is a very welcome change to allow better mod interoperability.

Provided a few suggestions. Feel free to reject if you think they don't make sense.

[SmallJoker]

Tried to create an area that is too large for a regular player. As expected, it still works.

LGTM. Will merge in a few days unless someone's got objections.

[a-tour-ist]

Minetest does it like this: https://github.com/minetest/minetest/blob/master/builtin/common/register.lua#L56-L59
At the first glance it might be tempting to use the same table (minetest.callback_origins), which however is not documented, thus not guaranteed to exist or work as intended. A separate table would be needed within this mod.

Thanks for that great hint! I hope I did it in the right way now. If not I would appreciate if someone with deeper knowledge would take that over...

[SmallJoker]

Tested by tampering tha function in internal.lua at L237:

AsyncErr: Lua: Runtime error from mod 'areas' in callback on_chat_message(): mods/areas/internal.lua:227: 
[Mod] areas: Invalid api usage from mod 'areas' in callback registerProtectionCondition() at mods/areas/internal.lua:237
stack traceback:
....

Your implementation works.