Demonstrates 3 issues with enums / token burns

[elmariachi111]

1 ERC3525.burn.ts This is actually due to an non standard behaviour that's not hit when using the HyperCertMinter:burn logic. This prevents burning tokens by their owner if the owner is not the original minter of the slot ("claim") and all the token's fractions aren't fully merged. On behalf of the underlying ERC3525 standard I'd consider it natural, that token owners might consider burning them (instead of looking for an instance to return their tokens to for free, first). If we're burning an nft with value, the nft is gone and the value is gone, too, effectively lowering the total circulating "value supply" without further notice. That might be what we want but maybe... the value could also be returned to the claim / slot owner during the burning process.

2 ERC3525.mint.ts tokenSupplyInSlot is part of the enumerable extension and part of the test suite I'm PRing against. However my test case demonstrates that the enumeration functions tokenInSlotByIndex and tokenSupplyInSlot fail / yield wrong values when called after an implicit value transfer to an address.

3 ERC3525.transfer.ts / HyperCertMinter.split.merge.ts Both cases demonstrate the same unexpected behaviour on primitive level as well as on client level. The totalSupply of tokens doesn't decrease after value merges.

[bitbeckers]

Added to refactor project board to make sure to update tests and take these findings into account