index.php, install/index.php: Add master $path variable

This replaces 174b9e7e "Don't repeat '../bonfire'", to allow configuring
install/index.php in the same way as index.php.  (Subsequent commits will
fix all the paths in the installer code, to respect this configuration).

As before - I'm not sure why this wasn't sorted properly, and this commit
doesn't exactly solve the problem.  It'll only help if you know to look
in the index.php files (both of them!).

Effectively this generalizes the earlier commit to "Don't repeat '..'".
The repeated "/bonfire" segment is fairly hard to miss, and this way could
be simpler.  Especially if you're not sharing one BFPATH between several
apps.
install: remove define(BFPATH) in favour of new define(INSTALLPATH)

public/index.php defines a BFPATH constant as pointing to bonfire/

The installer was confusing matters by defining a BFPATH constant
to point to application/.  Replace it with a variable,
Installer_lib::APPPATH.  Also provide ::FCPATH and ::BFPATH
variables to match; we'll use them later.

The variables are all derived from the same $path in index.php
(transmitted through an INSTALLPATH constant) - I'm not trying
to support sharing a BFPATH between multiple apps with these
changes.

This does not alter the standard CI _constants_ FCPATH and APPPATH.
I.e. inside the installer, these constants will still point to install/
and public/install/index.php respectively.
install: simplify paths using new variables

We can now remove these str_replace() shenanigans.
install: fix mistaken uses of FCPATH

Many of the uses of the FCPATH constant in installer_lib were wrong -
they wanted the FCPATH used by the installed app, not the FCPATH used
by the installer app.  The installer still worked because the affected
code is either dead or non-essential.

One affected instance of FCPATH.'../' can be replaced with INSTALLPATH,
so it now respects the value of the $path variable in install/index.php.
config_file_helper: don't call Modules::find() for null module

Installer doesn't have Modules, so this should let us share the code a bit
more freely.

Might also avoid some unexpected results.
Unify the config_file_helpers in installer & main Bonfire

Installer's write_db_config() had an $apppath option, to allow targetting
the real bonfire directory.  Add the option to write_db_config() and
write_config() in main Bonfire, then I can copy its version of
config_file_helper.php back into the installer.

This replaces the installer's hack for write_config(), so change the
callsite in the installer as well.

There was one other fix from the installer's write_db_config(), which
can easily be seen in the diff around file_get_contents().
install: remove two uses of APPATH.'../bonfire'
install: support relocated webroot in writeable files check
installer: factor out an installed_url() helper
install: fix missing lang keys in_driver and bf_language_dir

Fix in_driver to in_db_driver in the controller.

Refresh the installer's copy of application_lang.php from the main Bonfire,
so that bf_language_dir is available for languages other than persian.
install: fix search path for migrations belonging to custom modules

Just having 'bonfire/modules' is wrong (out of date), because this is used
to install migrations from custom _application_ modules.  (Bonfire _core_
doesn't have module-specific migrations at the moment).

I'm just copying over the locations from application/config/config.php.
I'm suspicious about '../..' in the values (it looks like an attempt to
break out of the public/ folder, but we want that to be relocatable).
However AFAICT the installer doesn't use the values, so it's ok for now.
install/views/complete: remove unintended space

The extra whitespace at the start of the first list item was affecting the
layout here.  (Firefox 19.0)
install: don't set files writeable; it won't work anyway (#707)

ColdIce1 was concerned about this.  I don't think it should be done without
notice either.   But mainly I don't see how it could work.  chmod()
requires being the file's owner, and the owner will have write access
already.

Maybe there were specific non-traditional situation(s) in mind, but it's
not clear from the comment :).
MY_Lang: implement all MX_Lang parameters to fix E_STRICT notices

Strict standards: Declaration of MY_Lang::load() should be compatible with
CI_Lang::load
Strict standards: Declaration of MY_Lang::line() should be compatible with
CI_Lang::line

I did feel a bit guilty at the time, but I was having difficulty parsing
all the sludge.  But with the basics cleaned up, I'm happy to have another
go at piling on the hacks.  The code will be significantly less readable,
but at least I've commented the sort of things I was struggling to grok.
Template library: fix non-static method (E_STRICT notice)

All the other Template methods are static; this one needs to be as well.

"Strict standards: Non-static method Template::find_file() should not be
called statically in /home/alan/php/Bonfire/bonfire/libraries/template.php
on line 857"... and 3 other places.
Context library: fix non-static methods (E_STRICT notice)

All the other Context methods are static; these two need to be as well.

"Strict standards: Non-static method Contexts::context_nav() should not be
called statically in
/home/alan/php/Bonfire/bonfire/modules/ui/libraries/contexts.php
on line 343"

"Strict standards: Non-static method Contexts::sort_actions() should not be
called statically in
/home/alan/php/Bonfire/bonfire/modules/ui/libraries/contexts.php
on line 432"
migrations module: remove config['migrations_path']

Remove the migrations_path config option.  We also notice that the removed
comment claims the path needs to be writeable - this is not true now, so
we can remove the corresponding check from the installer.

Even before the new directory structure, it didn't make any sense to change
the migration path.  (Bonfire looked in a "core" subdirectory for it's own
migrations, so you would have had to copy that over as well).

In the new directory structure, the application has its own migrations
directory.  But the config didn't allow you to change that.  It only
allowed you to change the bonfire/migrations directory!  (The installer
uses the corresponding constructor parameter, but that doesn't mean we
need a config option, and we could easily get rid of that if we wanted to
anyway).
migrations module: remove unused config['migrations_enabled']

Dead code.  (The config that works is migrate.auto_core.  The stock
application.php has config['migrate.auto_core'] = TRUE).
migrations module: remove unused config['migrations_version']

This only applies to bonfire core migrations, so it should never have been
used by applications.

This was the last option in the file migrations/config/migrations.php, so
I remove the file.
migrations library: remove unconditional debug line