The code is full of duplicated paths and can probably be shrunk
down to 50% of its current size, making it easier to follow,
debug, extend, yadda, yadda...

It's been confusing to say the least, resulting in multiple
misuses throughout the code.  The idea was that /cf pointed
to a read-write root, while / pointed to read-only root.
For non-embedded images this was emulated by linking
/conf -> /cf/conf, which, is a bit questionable because now
you can write from /conf as well and don't have to use /cf/conf
at all.

A couple of lines are left in /usr/local/etc/rc which need to
be reviewed so that migration paths are safe for all types
of firmware upgrades.

/tmp is unlikely to change.  If, however you decide to change
it to somewhere else the likelihood of someone else hardcoding
/tmp just to annoy you is so high that it simply makes no sense
to keep any softcoding in this regard.  More batches coming, but
since the usage is so widespread, I'll push it bit by bit.

Let's trust the routing on this one, so that when we have it we
won't trip over this stuff again...

Currently debugging #86 but the file is impossible to read...

These changes create instability on development images in
conjunctio with mount for core.git:  since files move they
exist in two places at once, maybe screwing up the system.
There's no sensible way other than asking for or building
a new snapshot package for opnsensense and going from there.

Seeing PHP ignore text files makes it easier to lint over more
files for a simple reason:  maybe someone sneaked a PHP file
into the repo and forgot the proper file extension, which is not
uncommon for utilities in *bin/ -- makes it easier to catch those.

* We can now see the errors we suppress.  E_WARNING is the one that
  should be zapped as soon as possible.

* According to the manual, display_startup_errors should not be enabled.

* Add ignore_repeated_errors to avoid multiple reports in e.g. loops.

While there, don't expose the main include file to the web server.

(1) It has been disabled since our first release.
(2) It is not part of our development workflow.
(3) It is quite dangerous and potentally fatal.

Quality is important; we hide PHP warnings so it's good to let
our beloved users/testers check and forward them regularly.  :)