SQL functions for improved pool statistics

A couple of new stored procedures and a new trigger has been added to
calculate the number of free and total prefixes available in a pool
based on the default prefix-length.

The idea behind this is to list the number of total / used / free
prefixes instead of just listing total / used / free addresses. Since
the default prefix-length of a pool is typically used when assigning new
prefixes from that pool, it becomes more interesting with the amount of
free prefixes than free addresses.

The number of used prefixes is defined as the number of direct childs to
a member prefix of the pool. Free prefixes should be the number of free
prefixes with the pool's default assignment size in all the member pool
while the total prefixes is used + free combined.

This leads to the slightly awkward side-effect that the total number of
prefixes in a pool can vary if non-default prefix-lengths are used.

Part of #528.
backend: add improved pool statistics

The backend will now serve the new prefix statistics columns of pool
over the XML-RPC interface.

Part of #528.
pynipap: support for improved pool statistics

Pynipap now also converts the new prefix statistics attributes on pools
similar to how its done for other statistics attributes.

One change is that the new columns might contain NULL values and if so,
we let them remain as NULL (None) to indicate that they could not be
computed.

Part of #528.
Update test case for improved pool statistics

Part of #528.
cli: add improved pool statistics

CLI now shows number of total / used / free prefix as per #528.

Part of #528.
www-ui: add improved pool statistics

This adds the improved pool statistics for showing total / used / free
prefixes per pool. There's a pretty graph, just like for addresses and
a text explaining the statistics.

Part of #528.
sql: split function and trigger defs into two files

This is required to properly load the database functions and triggers
during the upgrade operation.

The upgrade-4-5.plsql script needs to run a function that is in
functions.plsql but since functions.plsql also contains trigger
definition it needs to be loaded after the upgrade-X-Y files (which
usually contain table changes). So we have a cyclic dependency and the
easiest solution to solving it is to split the functions into their own
file which is loaded before the upgrade scripts and trigger script.

Part of #528.