Estimated virtual map size for NFTs and token rels needs to be adjusted

With data on disk, accounts, NFTs, and token rels are all stored in virtual maps. When the maps are initially created (during migration), size estimation is provided for each map:

```java
private static final long MAX_ACCOUNTS = 100_000_000L;
private static final long MAX_TOKEN_RELS = 100_000_000L;
private static final long MAX_MINTABLE_NFTS = 500_000_000L;
```

These numbers do not look right. For example, number of token rels is expected to be much higher than the number of NFTs.

At MerkleDb level, virtual map estimation is used to calculate the number of object key buckets. With the sizes above, there aren't many buckets for token rels, which implies a lot of collision (lots of keys with similar hash codes) in every bucket, which hurts performance.