Default to place prefix in same VRF

When the user allocates a prefix from another prefix, the new prefix's
VRF will default to the VRF of the prefix it's allocated from. To
simplify things the JSON encoded prefixes returned from the XHR
functions now include both VRF ID and RT.

Part of #286
Prefix's VRF now defaults to pool's implied VRF

When allocating a new prefix from a pool, the prefix will by default be
placed in the pool's implied VRF.

Fixes #286
Update pool VRF consistency check error message

The mapping of which prefixes belong to which pool is through the
pool_id column in the prefix table. As the database trigger that handles
the consistency is on the prefix table, the given error message was
oriented from perspective that the change is on a prefix - which is true
in the database. The user however, probably sees this from the
perspective of modifying a pool.

This new error message is from a slightly more neutral perspective. It
makes more sense regardless if you think you are editing a prefix or
expanding a pool (ie, modifying the pool).

Fixes #253
Fixed SQL query for parent_prefix

AFAIK, this does everything we want. I had to put in an extra condition
to the JOIN as that speeds up the query tremendously.

Hope it holds up in a production environment too. Test database I have
is few VRFs but in excess of 10000 prefixes so results should hopefully
not be too far off.

This fixes #206.
automatically inherit VRF from pool in nipapd

When allocating from a pool, nipapd now looks at the implied VRF of a
pool and sets the same VRF to the new prefix being allocated. It doesn't
work for from-prefix operations as the input argument to from-prefix is
a list of prefixes and not a list of IDs of prefixes, so they can only
be uniquely identified by being specified in combination with a VRF.

Part of #286
Fix VRF lookup

Part of #286 and #295
Merge branch 'cli-from-pool-set-vrf' of github.com:plajjan/NIPAP into cli-from-pool-set-vrf

Conflicts:
	nipap/nipap/nipap.py