Separate MappingService from LispMappingService

This is the last in a series of patches meant to enable independent
caching of northbound and southbound mapping registrations and
better modularize mappingservice.implementation. In
particular, with this patch we separate the MappingService, that
coordinates the storage and quick retrieval of mappings, from the
LispMappingService, which implements the LISP specific
MapServer/MapResolver behavior for southbound clients by leveraging the
previous service. To this end, apart from inheriting the RPC API,
MappingService also implements a new Java API that may be consumed as a
SAL service.

Functionally, the MappingService acts an API dispatcher that coordinates
and acts as container for all objects in charge of i) saving and
updating md-sal datastore stored mappings/keys ii) monitoring md-sal
datastore mapping/key updates and pushing them to the in memory
mapping-system iii) in memory mapping-system, which consists of a set of
mappings caches and a simple (for now) querying policy.

Other notable changes:
- declutter the MapServer/Resolver Java API hierarchy and update
  IFlowMapping API
- update ILispDAO and the HashMapDb to support the introduction of
  'virtual' tables. So we now have a Table->SubTable hierarchy and
  SubTables can be nested recursively.
- added IMapCache interface and 3 types of map-caches:
    o) flat: for flat addresses
    o) simple: for flat and IP addresses. It supports longes prefix
       matching for IPs.
    o) multi-table: for flat, IP and multi-level addresses (SourceDest
       LCAF for now). For IP and multi-level addresses longest prefix
       matching is supported.
- update unit and integration tests

Change-Id: I2532b04a9693f86c3ba87eddc982725fd12a429f
Signed-off-by: Florin Coras <fcoras@cisco.com>