Keys: Allow easy sharing of access without commands

This code adds the key concept to minetest_game, and integrates it
with lockable nodes. Currently supported lockable items are the Steel
Door, the Steel Trapdoor, and the Locked Chest.

The goal of this modification is to introduce a fine-grained multi-
player permission system that is intuitive and usable without any
console or chat commands, and doesn't require extra privileges to
be granted or setup. Keys can also physically be conveyed to other
players, adding to gameplay and adding some personality that is
preferable to console commands or editing formspecs.

A skeleton key can be crafted with 1 gold ingot. Skeleton keys can
then be matched to a lockable node by right-clicking the skeleton
key on a lockable node, which changes the skeleton key to a "key".

Gold was chosen as it's currently a not-so very useful item, and
therefore it's likely that players have some, but aren't really
using it for any purpose.

This key can subsequently used by any player to open or access that
lockable node, including retrieving items from Locked Chests, or
putting items in them.

They key is programmed to fit only the particular locked node it is
programmed to. This is achieved by storing a secret value in both
key and locked node. If this secret value doesn't match, the key
will not open the locked node. This allows many keys to be created
for one chest or door, but a key will only fit one node ever. The
secrets are stored in node, and item meta for the key.

If a locked node is removed, all keys that opened it are no longer
valid. Even if a new door/chest is placed in exactly the same spot,
the old keys will no longer fit that node.

Keys can be smelted back in gold ingots if they are no longer useful.

The method of storing a secret in nodemeta and itemstackmeta is secure
as there is no way for the client to create new items on the server
with a particular secret metadata value. Even if you could possible
create such an itemstack on the client, the server does not ever read
itemstackmeta from a client package.

The patch adds an API that allows other nodes and nodes added by
mods to use the same keys as well. The method how to implement this
is described in game_api.txt. The mod should add 2 callbacks to it's
node definition. Example code is given.

Textures are from PixelBOX, thanks to Gambit.

game_api.txt

@@ -672,3 +672,61 @@ Carts
 	like speed, acceleration, player attachment. The handler will
 	likely be called many times per second, so the function needs
 	to make sure that the event is handled properly.
+
+Key API
+-------
+
+The key API allows mods to add key functionality to nodes that have
+ownership or specific permissions. Using the API will make it so
+that a node owner can use skeleton keys on their nodes to create keys
+for that node in that location, and give that key to other players,
+allowing them some sort of access that they otherwise would not have
+due to node protection.
+
+To make your new nodes work with the key API, you need to register
+two callback functions in each nodedef:
+
+
+`on_key_use(pos, player)`
+ * Is called when a player right-clicks (uses) a normal key on your
+ * node.
+ * `pos` - position of the node
+ * `player` - PlayerRef
+ * return value: none, ignored
+
+The `on_key_use` callback should validate that the player is wielding
+a key item with the right key meta secret. If needed the code should
+deny access to the node functionality.
+
+If formspecs are used, the formspec callbacks should duplicate these
+checks in the metadata callback functions.
+
+
+`on_skeleton_key_use(pos, player, newsecret)`
+
+ * Is called when a player right-clicks (uses) a skeleton key on your
+ * node.
+ * `pos` - position of the node
+ * `player` - PlayerRef
+ * `newsecret` - a secret value(string)
+ * return values:
+ * `secret` - `nil` or the secret value that unlocks the door
+ * `name` - a string description of the node ("a locked chest")
+ * `owner` - name of the node owner
+
+The `on_skeleton_key_use` function should validate that the player has
+the right permissions to make a new key for the item. The newsecret
+value is useful if the node has no secret value. The function should
+store this secret value somewhere so that in the future it may compare
+key secrets and match them to allow access. If a node already has a
+secret value, the function should return that secret value instead
+of the newsecret value. The secret value stored for the node should
+not be overwritten, as this would invalidate existing keys.
+
+Aside from the secret value, the function should retun a descriptive
+name for the node and the owner name. The return values are all
+encoded in the key that will be given to the player in replacement
+for the wielded skeleton key.
+
+if `nil` is returned, it is assumed that the wielder did not have
+permissions to create a key for this node, and no key is created.