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 :).