including Brazilian Portuguese language for the system bonfire

Signed-off-by: adias <adias@sowebsites.com.br>
Merge branch 'develop' of git://github.com/ci-bonfire/Bonfire into develop
Upgrade Brazilian Portuguese language
installer: remove xss_clean

Explained earlier: xss_clean doesn't work.

installer was missed; probably I forgot
to search outside the bonfire/ directory.
installer: remove strip_tags

Explained earlier: strip_tags is wrong.

[And if your database _itself_ is vulnerable to malicious HTML,
 something is very wrong :)].

installer was missed; probably I forgot
to search outside the bonfire/ directory.
installer: do not trim password

Explained earlier: users will be very confused if we mangle their
passwords without telling them.
installer: password is not limited to alphanumeric with dashes

We have no such limitation outside the installer,
so having one here will only cause confusion.
admin theme: remove unused ajax loader (which has missing alt text)

Unused code suffers from bitrot.  (E.g. who knows if mobile__header.php
should include the loader?)

And the loader creates warnings on every page, about the image with no alt
text.  (That's not using any a11y tool; just the HTML5 validator).

Setting alt text might be an improvement, but there's more to providing
a11y than that when DOM manipulation is involved.  In that sense, the
current non-ajax admin interface is rather easier to reason about than the
old one :).
user_form: remove empty alert box

My fault (d13c4c06).
ui: remove unsafe DOM manipulation of form

Firefox "bfcache" (back-forward) caches the DOM state of pages in the
browser history.  This provides convenient performance and usability,
but it means you can't use naive DOM manipulation in a submit handler.
(I haven't tried to work out whether there's a event you can sensibly catch
to undo the manipulation; it's simpler to just rip out the JS nonsense :).


Here's the issue:
1. add a test shortcut
2. click its "remove" button
3. click the browser "back" button
 => deleted shortcut reappears
4. click "save"
 => Expected behaviour: deleted shortcut is recreated
 => Actual behaviour: error message complaining that the shortcut could not
    be deleted
database controller: remove dead line

In order for this to take effect it should be set_block() instead of set(),
the controller would have to use a non-default layout, and there would have
to actually be a file core_modules/database/views/admin/sidebar.php.
database controller: nitpick the optimize() error message
database controller: fix DROP

(It would claim success, but fail to delete the table(s).  Let's at least
fix the latter problem).

I guess it's understandable if people haven't been eagerly testing this
feature :D.
Fix the "save" keyboard shortcut (#645) and avoid using "name=submit"

Why:

- #645: I broke "ctrl+s: Save any form in the admin area."

  > The JS keys off name="submit".  In some forms I had changed this to
  > name="save".  [Because] I misliked having some forms with name="submit"
  > to represent "save", and an alternate submit button with name="delete"
  > ...

- ctrl+s should not perform dangerous actions like deleting tables, because
  the user may have intended to invoke a harmless browser shortcut.

- One page - the emailer settings - had two buttons with name="submit", the
  settings page and the test form.  There was no comment to indicate what
  behaviour was expected when hitting ctrl+s here.

- name="submit" should not be used, because it masks the DOM submit()
  method on the form.

  http://stackoverflow.com/questions/3571328/form-submit-button-will-not-submit-when-name-of-button-is-submit

What:

 - Change the shortcut to key off name="save".

 - Use name="save" for all "save" buttons.  I include "create" as well,
   but I do not include more general actions, such as deleting tables.

 - Set new names for all the other submit buttons :).

 - Update controllers to accept the new names.
Add post_key_exists(), use it to improve code consistency

This avoids the uncommented use of isset() and $_POST, particularly
in the output of the module builder.
Language fix v1.
Cleaned up to use sprintf.
Fixed lang-keys, indent too.
database controller: remove old delete() method
database controller: backups(): remove Windows-centric no-op

Having write permission to a file doesn't mean you can delete it.

Presumably this was designed with Windows in mind - it's trying to check
whether another instance of Bonfire has opened the file.  But you can't
delete open files on Windows anyway.
database controller: refactor backups()