Initial API refactorings for multi-tenancy.

Muli-tenancy is the idea that there can be multiple tenants that have their own set of tables:
 * there is no data sharing between tenants: e.g. a table of one tenant cannot link to a record in a table of another tenant
 * on the hbase level, tables are named "tenantId__tableName". For compatibility, there is a public tenant, and for this tenant the table names do not contain the tenantId, so for the public tenant the record table is just called "record" and not "public__tenant". The use of "__" will be forbidden in tenant and table names.
 * the RepositoryTableManager is also scoped per tenant
 * for now, the concepts of TypeManager and IdGenerator stay shared between tenants, this might change later on. Iow, there is one schema for all tenants.

This commit introduces some first API changes for multi-tenancy.

The API concept is:
 * RepositoryManager is a factory tenant-specific Repository objects
 * Repository is a factory for LTable's
 * LTable provides access to all CRUD operations on records in a specific Table

Thus compared to before:
 * LTable takes the role of what Repository did previously
 * Repository takes the role of what RepositoryManager did previously
 * RepositoryManager gets the new role of tenant-dispatcher

This brings the API more in line with the conceptual model, i.e. different tables are not different repositories, and each tenant has its own repository.

The changes should be backwards compatible with released APIs, but the change to RepositoryManager is incompatible, but this is new functionality which was not yet released anyway.

The compatibility is achieved as follows:
 * Repository extends from LTable
 * LilyClient.getRepository() returns the repository for the public tenant and the default table. Since repository extends from LTable you can do everything you could do before.
 * Repository.getTable(name) returns an LTable. This means that code that wants to make use of tables other than "record" would need to be adjusted to use LTable. To avoid this, you can cast the LTable to Repository.
 * The above basically means that in implementation, Repository and LTable are still the same and implemented by the same object. But this is only for compatibility: new code should be written against LTable.
Fix compile errors introduced by mutltitenancy api changes

Also making RepositoryTableManager multitenancy aware.
TableManager adaptations for multitenancy

RepositoryTableManager should now be per-tenant, and Repository serves as a factory for obtaining the tenant-specific RepositoryTableManager.

RepositoryTableManager did not yet have a remote equivalent, and since it now needs one, added the remote impl. I wrote all this code without any tests for it, so it probably doesn't work. To be done later.

I had to slightly refactor TableConfigBuilder as well as part of this, cfr the parsing of the input parameters into "byte[][] splitKeys".
Introducing tenant management.

 * Through TenantModel tenants can be created, updated and deleted.
 * Creating and deleting tenants are not immediate: they put the tenant in a certain lifeycle state which is picked up by a TenantMaster which does side effects like creating or dropping tables. This makes that if a lily-server is killed halfway through, or if no lily-server is running, the operations will still be picked up later. The implementation is based on the IndexerModel.
 * Because 3rd party components might need to do things when tenants are created/dropped (e.g. indexer should drop derefmap tables), there is a hooking mechansim for the TenantMaster. For example, even the creation of the default record table is done this way (simplifies dependencies).
 * RepositoryManager is dependent on TenantModel as it needs to verify whether tenants exists.
 * Added a first testcase for tenant/table related stuff (AbstractTenantTableTest).
Rename RepositoryTableManager to TableManager.

I found the former too long.
Rename tenantId -> tenantName

I found it strange to use the combo (tenantId, tableName), so made tenantId also into tenantName.
This commit also includes RepositoryTableManager -> TableManager renames which should have been in the previous commit, sorry.
multitenancy: minimal runtime wiring changes

to make lily-server start again
multitenancy: min changes to make lilyclient work
multitenancy: introduce admin cli tools
Add startup of tenant master in lily server

The tenant master is started in a module of its own.

And:
 * introduce use of PluginRegistry to register TenantMasterHook's
 * add registration of RepositoryTenantMasterHook as part of lily server startup
Adding tenant option to some cli tools

Since both tenant and table start with t, thought it was best to use only long options (-t option for table was not yet released).
New tenant-module, forgotten to add earlier
Adjust importlib to be repository based

since the role of RepositoryManager is now to give tenant-specific repositories, and since most code should be tenant-scoped it needs to be written against Repository.

Also changed lily-scan-records to be based on LTable instead of Repository, just to check if the mulitenancy-related API changes make sense. Found a need to introduce a PureRepository to protect against unintended use of LTable methods through Repository.
Remove Repository.getRepositoryMgr and its usages

These were mostly usages that were written with the previous notion of RepositoryManager dealing out table-specific Repositories.
Remove method Repository.registerBlobStoreAccess

Seems like the wrong place for it, behavior is unclear (should I do this on the client, the server, or both, and when?). I'm taking the assumption no one used this.
core repo api change: introduce LRepository itf

Introduce an LRepository interface to which the methods from Repository, which were not yet moved to LTable, are moved. Repository is now just the combination of LRepository and LTable. Rationale for this is that otherwise using Repository will be error-prone, since it allows for unconsiously calling LTable methods on it. Once everything is moved to LRepository/LTable, we'll also have a better separation of concerns.

Also changed the signature of RepositoryManager.getRepository() to return LRepository objects. This actually had the widest impact, since in most places it required casting back to Repository.
Change some code to use LRepository

Change some code to use LRepository instead of Repository: the scanner-cli tool and as dependency the import lib.
Fix incorrect uses of RepositoryMgr.getRepository
Rename isLilyRecordTable

Rename the hbase metadata property isLilyRecordTable to lilyTableType with as value record. Previously the value was Bytes.toBytes(true), which is unreadable in the hbase webui/shell.
Delete all record tables except for the default

This is required for tenant/table related tests to work in connect mode (unless we would review that code so that it doesn't fail when creating the same table twice).