Refactor: Automate the management of i18n keys through i18next-parser

[WhiteMinds]

This helps to improve maintenance efficiency and avoid issues with i18n key management chaos.

[WhiteMinds]

Refactor to use the same technical architecture as the neuron project in https://github.com/Magickbase/websites, which means it will be refactored into the usage form as shown in the following diagram.

[WhiteMinds]

Changes in the originally expected development process

Original process:

1. Look for an existing old key and consider whether the namespace (ns) it is in is suitable for the current component.
2. If it does not exist, think of a new key name, consider which ns to put it in, and then use it in the code.
3. Open the en and zh configuration files, find the corresponding ns location, and put in the new key and value.

Refactored process:

1. If it is non-generic text, use the page or component's private ns directly, and wrap the original English sentence directly with the t function.
2. If it is generic text, such as noun explanations, use ns and key in the original way, and the t function needs the ns parameter.
3. Run yarn i18next, and then fill in the zh value in the zh configuration file.

After some actual trials, I found some problems. i18next-parser will only mark one defaultNamespace per file (the last one). This means that multiple different defaultNamespaces cannot appear in a code file, for example, having both useTranslation('address') and useTranslation('nervos_dao') is not allowed.

This limitation will lead to some constraints in the development process, and these constraints cannot be simply emphasized directly in the code. Therefore, I believe this change will lead to some complexity in maintenance, so this issue will be suspended for now.