users model: remove temp assignments to table/key that don't do anything

Mentioned to us as issue #778, "Hardcoded table name"
users model: don't try to insert NULL username; this field must be NOT NULL

update() didn't try to do this.  Rip it out.

This fixes a database error when creating users with an empty username,
which is expected to work (if you've set auth.use_username=0).

(We still don't support empty usernames properly, because it stops you
editting users - issue #659).

Thanks to @artlantis for pointing this out in issue #783.
emailer lib: remove incorrectly used errors array

It was used correctly as an array in only 1 out of 5 places. The others
would cause PHP errors when an email error was encountered, which is
not very helpful.

(I.e. there needed to be an easier way of printing the array - something
 like emailer->errors_as_html())
Fix #768 User_model->find_by('both') behavior

- Moved logic for auth library into the auth library.
- Updated find_by() and find() to accept same arguments as the parent
model and pass them to the parent.
- Used lang('bf_both') for the check in the auth library, @sourcejedi
notes bf_both is not functional in non-English environments, so it must
either be added or both instances changed back to 'both' in the login
function
- Kept the "magic" $type and $return_type variables in the
newly-extended methods.
User_model: use variables for table names (#778)

Added variables for user_meta and roles tables and updated the
User_model to use them instead of the hard-coded table names. Also
replaced a few instances of the users table.
user_model->activate(): $code parameter is not optional

PHP error messages are our friends.  They tell us developers when we've
forgotten to pass a required parameter to a function.  They even give us a
backtrace[1] that shows the exact file and line of the call that needs
fixing.  Welcome the error messages, by ensuring required parameters do not
have default values.

[1] Backtraces may be void if suppressed by CodeIgniter's default error
handler.  I'm getting them at the moment without modifications to CI...
they are coming through xdebug though.

Please do not re-implement PHP's own error messages and ask people to
translate them into their native language.  Developers speak English,
at least to the point of understanding the error messages of their
programming language.

(To be fair, there's an exception in the case of public methods on
CodeIgniter _controllers_, which can cause some confusion.  With those
methods the parameters are taken from URLs.  It's usual to provide default
values to suppress PHP errors, and show something slightly less alarming to
the unfortunate user).
model->find_all(): remove "Invalid selection" error for empty results

This generates log noise.  E.g. when visiting any page with the profiler
turned out but without permission to view it

DEBUG - 2013-04-10 09:07:17 --> Auth class initialized.
DEBUG - 2013-04-10 09:07:17 --> Bonfire MY_Lang: Language file loaded: ../application/language/english/application_lang.php
DEBUG - 2013-04-10 09:07:17 --> File loaded: /home/alan/php/Bonfire/bonfire/modules/permissions/models/permission_model.php
DEBUG - 2013-04-10 09:07:17 --> Model Class Initialized
DEBUG - 2013-04-10 09:07:17 --> File loaded: /home/alan/php/Bonfire/bonfire/modules/roles/models/role_permission_model.php
DEBUG - 2013-04-10 09:07:17 --> Model Class Initialized
DEBUG - 2013-04-10 09:07:17 --> [Role_permission_model: BF_Model::find_all] Invalid selection.

(backtrace:
5	0.2327	3504544	Base_Controller->__construct( )	../MY_Controller.php:183
6	0.2494	3883288	has_permission( )	../MY_Controller.php:121
7	0.2494	3883440	Auth->has_permission( )	../auth.php:978
8	0.2543	3990520	Auth->load_role_permissions( )	../auth.php:490
9	0.2544	3990776	Role_permission_model->find_for_role( )	../auth.php:580

Supposedly it's simultaneouslly an unimportant debug message, and a
user-facing error message that requires translation.  The message text
looks equally unhelpful for either case.

(The real WTF as they say, is that we're still forcing the caller to handle
empty results as a special case, by returning FALSE.  And then not
documenting how to distinguish this from a database error).
user activation: don't put emails in urls, CI forbids it (issue #785)

CI has a mandatory error "The URI you submitted has disallowed characters"
for certain characters.  Email addresses can contain lots of characters,
including at least one that CI doesn't like (I think it was '+').

The activation URL used an email address to specify the user.  Use the
user ID instead.
users controller: don't use non-existent lang('us_activate_error_msg')

It was largely covered by 'us_err_activate_code' already.

This avoids a "FIXME ('us_activate_error_msg')" appearing (from the revised
language class).
users auth library: fix error message + Mats new code for not-English

Issue #788
Some small fixes
Some small fixes
Merge pull request #791 from LeonardoCaitano/patch-2

Small fixes for portuguese_br
Merge pull request #790 from LeonardoCaitano/patch-1

Small fixes for portuguese_br
gitignore: install/logs/*

(Currently they only appear if you've created that directory yourself
for development purposes.  But I have, and it was cluttering my IDE).
migrations controller migrate_to: fix one error message

Don't overwrite the error message if migrations fail!

The error case is probably still broken generally, see #757, but this part
is an obvious coding error.
migrations controller: fix CSRF vulnerability

I must have forgotten about migrate_to() at some point during the audit.

migrate_module() wasn't vulnerable.  But we should make that _obvious_ by
making it look the same.  (It may have been why I forgot about migrate_to).
database controller: CSRF cleanup

These might have been exploitable to DoS the database.

Or in the case of get_backup(), cause strange things to happen by
reading from an arbitrary device file.
Remove stray error message in migrations

Removal of redirects in commit #52dc58de0ecc67374d112002eb31ed01cc43a11c
caused invalid error message to override normal migration messages
Fix: Unstyled Emailer sub-menu in Settings menu

When a submenu is built from only one module, the Contexts library was
not applying the Bootstrap classes to the submenu. The change in
build_item() actually just places most of the method's prior code into
the if (empty($menu_view)) condition. The else portion uses primarily
code adapted from the build_sub_menu() method.

More than likely there's a more efficient way to handle this, at least
from the standpoint of code reuse (if not performance).