Change parser to load modules on demand

On each line of the config file, the parser used to check if child
modules matched the lines regex.  To do this it loaded all candidate
children modules then at each new line would check them all.

The problem with this is that the loading is largely unneeded and
resource intensive.  Any module like "include" that had a bunch of
possible children would end up loading all those modules even if the
include file was blank or never parsed.

This potentially fixes #6.
removed "children must be grouped" in add_child

This runs a whole bunch and takes up lots of time but I can't figure out
why it's there.  My guess is that remove_child might use the fact that
children are grouped to only look at next children once it's found the
right class type.

If so, there isn't a unit test for this.. and we're facing a couple of
tradeoffs depending on if the user calls remove_child a bunch of times.
Essentially, I think add_child would be faster but remove_child would be
slower. (and broken right now FWIW)

We could trade memory for it and store a hash table of children, making
them faster to search.

My current reasoning is this:

In a 1 million line dhcpd.conf file, we need to call add_child 1 million
times.  Even if the user does heavy deletes they probably aren't
doing as much as the initial add, so I think add_child should be fast
and remove_child can be slower.
if ($children) is always true
adding tests for remove_<classnames>

This doesn't cover all of them, but the idea is to make sure the concept
works and is tested.
Merge pull request #8 from jhthorsen/config_speed_parse

Merging these changes because it doesn't appear to break anything.