Adding a UI_InfoView UI element

It displays formatted information. It has a data source and an enum to
identify how the data from that source should be interpreted and
represented.
Adding submap_first_item_at()

Returns the first item at the given coordinates.
Adding a testing ',' input to pick up items

And it works! Picking up the items correctly puts the 'test' on the
ground into the player's 'hand' attach point and it gets removed from
the submap.
Fixing another small dynarray oops
Separating part of the submap event processing code
Adding a BIT(x) function to get flags from 1-32 values
Robustifying the methods for getting AP's from objects

They now have flags! For AP's which represent hands, feet, eyes, etc.

Any AP that has a specific non-holding-stuff function should have these
flags. Hopefully this will provide enough room for content (these AP's
will have to work for animal limbs, gun parts, backpack pockets, so the
flags have to be super-generic)

AP's can be retrieved by criteria, so for example if you want an object
to pick something up, you might request an AP with the AP_GRASP flag,
then put the picked-up object into that AP. Normally a hand would have
the AP_GRASP flag, but this allows any similarly functional limb to pick
stuff up too; a tentacle arm could have the AP_GRASP flag, for example.

Also, objects now hold an enum representing their relationship to their
parent. OBJ_WORN, OBJ_HELD, etc.
Fixing a memory leak in RL_DestroyObjectAP()
Simplifying the Object -> Parent relationship
Renaming create_listnode() to listnode()
Changing utility.h up a bit

And utility.c is making a return to hold that tiny little mod()
implementation.
Basic implementation of the text log.

It's a UI element that takes lines and puts them in a linked list. They
are displayed from the newest at the bottom to the oldest at the top.
Moving source files into lower directories

For organization
Starting to improve the game state system

Self-contained state implementations can now coexist in the
"game/game_states/" directory. All the functions should be static, and
pointers to the functions are filled into the game's state object in the
set_state functions.

`game_set_state()` is visible to all from game_states.h. It calls hidden state-
specific functions like `game_set_state_gameplay()` or
`game_set_state_mainmenu()` which are defined by the state
implementations themselves.

States are allowed to have their own self-defined generic data, accessed
through the `void* data` in `struct game_state`. Anything that only it
needs to worry about should be there. Only data required by all game
states should be left in the `struct game` definition when this is done.
Fixing build.sh

Such noob build system lol
Optimizing the UI text log element
Added UI_RemoveChild() to remove UI elements without freeing them

In this way different UI trees can be attached and reattached to each
other.
Moving almost everything about the gameplay state into the gameplay state

The only thing still left in the top-level `struct game` is the
eventqueue, which should be moved into an overworld object along with
the grid of active submaps eventually