ZNS Token Upgrade

Although the new implementation contract has removed snapshot functionalities during token transfers, it is still possible to access `ERC20SnapshotUpgradeable` public functions `balanceOfAt()` and `totalSupplyAt()`.

It is crucial to validate inputs, even if the inputs come from trusted addresses, to avoid human error. A lack of robust input validation can only increase the likelihood and impact in the event of mistakes. Following is the list of places that can potentially benefit from stricter input validation: 1. qs-badge-fixed `MeowToken.sol#37`: the `amount` of the `transferBulk()` should be greater than zero. 2. qs-badge-fixed `MeowToken.sol#56`: the `amount` of the `transferFromBulk()` should be greater than zero.

The new implementation contains an initialize function that mints tokens to the initializer address. If minting is not needed and is used for testing only, the minting function should be removed from the initialize function. Otherwise, anyone can invoke the `initialize()` function of the implementation contract and mint arbitrary tokens. In general, leaving an implementation contract uninitialized can pose a security risk. To mitigate this risk, it is recommended to invoke the `_disableInitializers()` function in the constructor during deployment (see: [OpenZeppelin doc](https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#initializing_the_implementation_contract)). This action will automatically lock the implementation contract, preventing any unauthorized usage.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.8.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version *and above*, hence the term "unlocked".