script and event libraries completely rewritten

Commands and events are now registered and run in an entirely different
way. Scripts have been restructered to match.

Scripts are now instantiated, run, and then discarded for each command
or event. This is done by calling instance_eval on the class with the
provided block.

To create a script command, you no longer use register_command. Instead,
use this format:

command 'command_text_here' do
  # your code
end

For example, for a simple ping/pong command:

command 'ping' do
  reply "pong"
end

For events, use:

event :event_symbols_here do
  # your code
end

You may use multiple event symbols, separated by commas, to run the same
block of code.

Code written in your script is run when the script class is created. It
is evaled inside the initialize method, so you cannot declare functions
here and access them later. To do this, use the `helpers` block:

helpers do
  def your_func
    # do something
  end

  def your_other_func
    # do something else
  end
end

A new event has been added: `:done_loading`. The event is fired when a
script is done loading, but ONLY the script that just loaded receives
the event. This is useful if you need to run code that requires helpers
and/or should only be called when the script is loaded, not each time
the class is instantiated during events/commands.

In other situations, just include your constructor code in the top level
of your script text, as it will be run each time the script class is
instantiated.

Because scripts are instantiated during each event and command, you
should not store data in instance variables if you will need it across
multiple events. Instead, use class variables (@@variable_name).

The msg and param values are no longer passed to scripts. They are
stored in the class variables @msg and @params.

The Message class no longer handles sending data. Instead of `msg.reply`,
you must use `reply`. This applies to:

* reply
* raw
* send_privmsg
* send_notice

Channel mode checks have been removed from the Message class.

The `private?` function has been renamed to `query?`.

Scripts have access to the following functions at any time:

reply - send a reply to the user that created the event or command
query? - return true if the sender is speaking in private
channel? - returne true if the sender is speaking in a channel
me? - return true if the bot is the sender
argc!(num) - raise an error if there are less than num command args
level!(num) - raise an error if the sender's access level is less than
              num
channel! - raise an error if the sender is not speaking in a channel
query! - raise an error if the sender is not speaking in private
op! - raise an error if the sender is not a channel op
half_op! - raise an error if the sender is not a channel half-op
voice! - raise an error if the sender is not voiced
send_privmsg(dest, str) - send PRIVMSG str to dest
send_notice(dest, str) - send NOTICE str to dest
raw(str) - send str over the IRC link

The commands ending with a ! are meant to be used to enforce one or more
conditions. For example, for the eval script:

command 'eval', 'Run raw Ruby code.' do
  level! 10 and argc! 1
  # ...
end

This requires that the sender has level 10 access and sent one command
parameter. You should not handle these errors; the command event
dispatcher will tell the user what is wrong.

You may include those at any point in your command handlers. This way,
if you have subcommands, you can enforce conditions within those.

There is probably something I am forgetting. This was a rather large set
of changes. If you have any questions, please drop by #botters on
Freenode and highlight me (Kabaka).