Localization support

Bắt đầu bằng việc xem xét branch i18n hiện có và các entry point ParametricBuilder và CommandGraph được đề cập trong issue, sau đó lần theo các thông báo runtime được hard-code cũng như phần mô tả và trợ giúp của các annotation lệnh. So sánh phương pháp Java ResourceBundle được đề xuất với hành vi hiện tại và phần thảo luận trong chín bình luận. Công việc được hoàn tất khi có một thiết kế bản địa hóa linh hoạt đã được thống nhất, bao quát các thông báo nội bộ và văn bản lệnh bên ngoài.

Intake should provide some sort of support for localizations. This affects two fields:

1. Internal localization: All hard-coded strings should be externalized in a Java ResourceBundle and some behaviour might need to be updated in order to work as expected in an localized environment. Some points might need discussion:
   • Intake has several internal runtime exceptions that the end-user should never see (e.g. ParametricException). These might not need localization.
   • It might be a good idea to allow users to alter or replace the internal localization logic by providing custom translations. In that case the two entry points are ParametricBuilder and CommandGraph.
2. External localization: The values in command annotations, specifically description and help, need localization support. The entry point here is the ParametricBuilder.
   • If localizations use key -> value relationships, as enforced by Java resource bundles, description and help methods would need to return the key. This contradicts the current behaviour where both methods return the actual value, so a support for that old, non localised behaviour is needed.

On both fields, the support should be as flexible as possible and do not enforce any specific way of handling Locales on the user.

Since I need localization support in MyWarp, I have implemented a limited localization support in my own Intake fork (i18n branch). I would be happy to contribute these changes in a PR so there is something to discuss about, if the general direction fits.