Fix #812 (take 2) Run list_fields() on the query

Running $this->db->list_fields($this->table) resulted in an older field
list being returned from somewhere in CodeIgniter/PHP/MySQL's depths.

Running list_fields() directly on a short query against the table
results in the correct field list.
Fix some permissions created by migration

Bonfire.Emailer.View, and possibly some other permissions, would
sometimes not install properly when the permission system was upgraded
in the migrations.
Changed require to require_once to fix issue 814
Merge pull request #815 from SethArchambault/develop

Changed require to require_once to fix issue 814
Fix #803 *breaks compatibility of old migrations

breaks compatibility of old permissions migrations (001-003), so users
trying to upgrade very old systems may need to pull the older versions
of those files.

Replaces the '.' with '_' in the column names in the old version of the
permissions table.
003_Permission_system_upgrade reverses the change when creating
permission names from the column names of the old permissions table, so
the new (current) permission names retain the '.' previously used in the
old table's column names.

Also added 'null' => false to field definitions that did not include an
entry for whether null is permitted, so we don't make assumptions that
may be invalid based on the defaults for a particular database.

Added a variable to hold the role_id for the Administrator user to
migrations that used it. This should both improve the clarity of the
code that uses it and make it easier to change the id if necessary.
Update MY_Model::delete tests for 668247876b0f2d4fce10625eb703758e8d422eb2

Changes to the delete methods in
668247876b0f2d4fce10625eb703758e8d422eb2 resulted in failures in the
tests. Since the tests did not break based on the function results, I've
updated the tests to reflect the changes in the model.

One item I did not fix is that the tests don't handle method chaining on
$this->db properly, so the tests error out when they encounter any use
of this feature.
Fix #630 Builder: Update Table Name when module name is changed

Added a JavaScript function (bonfire.builder.prepTableName()) to prepare
the module name to be used as the table name (further information
below).

Updated show_table_props(), which executes on load and when clicking the
create table/existing table radio buttons to use the function, passing
the tblName variable to preserve the existing behavior (only updates the
table name when it is empty if clicking the radio buttons).

Added event handlers to the module name input (on click, focus, and
blur) to call the function with an empty value, causing the table name
to update any time the user interacts with the module name. It may be
desirable to modify this to just use the change event, which can be done
by modifying the last line of the file to the following:
$('#module_name').on('change', {valueToPrep: '', setTableName: true},
bonfire.builder.prepTableName);

prepTableName takes an object as its only argument, with all valid
properties (and their default values) listed in
bonfire.builder.prepTableDefaults. The function also works as an event
handler, in which case it expects to receive an event object with a data
property which acts as the function's normal argument (this is the
behavior when passing the object to jQuery's $.on() method to bind an
event handler).

If the valueToPrep property is empty (the default), it will pull the
value from the module name field (or any field indicated with the
moduleNameSelector argument).

If the setTableName property is true (the default), it will output the
prepared value to the table name field (or any field indicated with the
tableNameSelector argument).

The function always returns the prepared value (unless there's an error
of some sort that prevents execution).