Added type hints to all __eq__() defs.

Just discovered type hints. The __eq__() other missing out on renames was
bugging me; fixed now.
Going to stop here and plan.

So.

There are a few ways this could go, and I'm not sure which is the best
way. Let's enumerate.

	Place the recording in the *called* functions of the events you
	want to record. For example, if we want to record if something is
	damaged, place the recording in the Destructible.deal_damage()
	function. If we want to record movement, log it in the
	Level.move_entity_from_to() function. This way, you will always
	log it (you can't forget to add the logging message!) but you get
	less data - you don't know who dealt the damage, for example.

	Place the logging in the *caller* of the events you want to
	record. For example, place it in BehaviorAttackMelee, or
	BehaviorMoveAStar. You get more data - you know that A damaged B
	for X damage - but it's a little more fragile because at some
	point, I *will* forget to log something I do and I'll notice it
	two days later and it'll drive me bonkers for twenty minutes.

	Go back to the Command thing, and restructure the program such
	that the only way to manipulate the actors/levels is through the
	commands. This neatly solves the problem of logging because now
	the logging is recorded in the action itself, and you can't
	forget, but on the plus side you can still have records like "X
	damaged B for Y." It also requires a non-trivial amount of
	restructuring and rewriting, for a not-amazing payoff.
		On the other hand...
	Structuring it with Command-style requests means that, if in the
	future I wanted to do more sophisticated things with the records
	(undoing, replaying, whatever) it'd be easier. But! Will I need
	it? It's of course nice to have options, but if you never use
	them...

Hmm...
Creating a View for Level.

I'm going to go with creating Commands. Entities and other objects will be
passed a View, which cannot be changed with direct function calls; changes
they wish to make must be instead registered as a Command object.

First step is creating the View object.
Modifying UI to work with View.
Converting LoaderEntityIndex to pass View.

Note that the create_instance now takes a view, not a level. This means
the currently-implemented method for handling eids is outdated and
inadequate.

Wrote a test for eid handling. Next, will change it so as to properly
handle.
LoaderEntityIndex now holds Level to create for.

LoaderEntityIndex.lvl should be set to the Level object for which you wish
it to create entities.

This is picky and easy to forget, but the *only* time it should change
should be in the LevelLoader._load_level() function, so it shouldn't be a
big deal.

Watch it bite me in the back two weeks from now.
Find-replaced warn(e) /w warn(e.message).
All non-entity tests pass.

Next, I will create a Command system to allow Entities to interact with
the Level data.
CompoundCommand, CommandFragment created.

Record is now CommandLog, serving the same purpose, but with, well,
commands.
Test for CompoundCmd.
CompoundCommand done.
Backbone for Commands is set up.

Past 5, leaving library. Next - start replacing the Entity classes'
attempts to access Level with commands.
Removed reference to Actor.

Was using isinstance(entity, Actor). Instead, now uses hasattr(entity,
'max_moves') to check if it has, well, moves.
Changed entity.destroy().

Now registers a CompoundCmd(LevelRemoveEntity).
Removed add_tool() function in Actor.

It was really only being used for testing purposes, so it was not worth
converting to a Command. Removed instead.
Adding docstrings.

Docstrings added to level.
More documentation, disambiguations.

Changed Level.get_all_entities_at and Level.get_all_entities to
Level.get_all_eids and Level.get_eids_at. Did *not* change the
implementation! Just the names.
Actor done. Did not require large changes.

Note that turn_begin() and turn_end() don't use Commands! This is because
turn_begin() and turn_end() do not change any data outside of the Actor
instance for which the function is called.

On the other hand, we lose the 'logging' functionality of the Command, so
maybe I'll come back and change it later, or subclass/rearrange Command
class hierarchy to put in something similar to the Record class. Right
now, though, I'm leaving it.
Split Sense.detect_entities, added is_active.

Added an is_active attribute to Sense. Sense.detect_entities() now checks
to see if it's active; if no, returns empty. If yes, defers actual sensing
to the subclass' _detect_entities() function.
Wrote a couple of tests for peace of mind.