Enhance navbar search to also look for aliases and addresses

This patch introduces two new configuration options to cgi.cfg, with
the obvious implications:
  * navbar_search_addresses causes the quicksearch thing to also scan
    host addresses when looking for matches.
  * navbar_search_aliases causes the quicksearch to also scan host
    aliases when looking for matches.

The options are turned on by default but can be disabled by setting
the necessary options in cgi.cfg.

Signed-off-by: Jonas Meurer <jonas@freesources.org>
Signed-off-by: Andreas Ericsson <ae@op5.se>
nebmods: Stop with the move-nebmod nonsense

The explanation for why we did this was thus:

> The problem with loaded modules is that if you overwrite the original
> file (e.g. using 'mv'), you do not alter the inode of the original
> file.

Correct.

> Since the original file/module is memory-mapped in some fashion,
> Nagios will segfault the next time an event broker call is directed to
> one of the module's callback functions.

Of course it won't. Why not? The first quoted sentence explained it
perfectly - the same inode still points to the same fil, so putting
another inode in the original path won't make one bit of difference.

What would cause a segfault, though, is truncating the module file and
filling it with new content so the addresses of symbols change while the
inode stays the same. You shouldn't do that.

> This is extremely problematic when it comes to upgrading NEB modules
> while Nagios is running.

To sum up the above: no, it isn't.

In addition to having a bogus reason for existing in the first place,
the code itself is problematic: it tends to cause an accumulation of
weird and nonsensical nebmod files in your var directory over time,
while also breaking any sort of clever debuginfo scheme employed by most
linux distros today, because the debuginfo can't be tracked down when we
invent new, faked names literally only in order to confuse linkers.

(ae's comments):
While it's true that a new inode will point to a new file, most
programs that need to write to the output file tends to do
open(path, O_WRONLY | O_CREAT | O_TRUNC), which truncates the file
rather than removing it first, and then we end up in the segfault
place again. However, this doesn't appear to be a problem on later
linux kernels (based on *very* rudimentary testing), and it does
make us mimic how apache uses dlopen() exactly, so it's apparently
more than possible to work around any and all problems.

For module authors, a good step is to add rules like this to their
makefiles, which avoids the trouble when rebuilding a module that's
currently being tested:
ndomod.so: all.o the.o happy.o object.o files.o
	rm -f $@
	$(CC) -fPIC -o $@ $< $(LIBS)

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
Signed-off-by: Andreas Ericsson <ae@op5.se>
Make cgi's build again

Meh. Changing a variable name from a patch without even trying to
build it is stupid (mea culpa).

This fixes up commit 2a5c6d1f3e0cd48ec6489e188ed7abc321873cfa,
which was good the way it was and which I screwed up somewhat.

With this patch on top, things are just peachy once again.

Signed-off-by: Andreas Ericsson <ae@op5.se>