GuideBook stuff

[Yefancy]

I felt like I had accomplished my initial goal, although it turned out to be much more than a Guide Book. However, I didn't have much time later, so I requested to merge this branch. And the code is already a lot, if continue to develop it will be more difficult to review. (Subsequent development will create a new branch, as it is beyond the scope of the guide)

First explain what was done, then give a brief description of what was changed. This introduction will be a bit long, but will be helpful for review and future development.

Changes:

1. Widget system.

Additions:

1. The Terminal System (GTOS? Tablet?) And includes subsystems such as Menu, Dialog.
2. GuideBook App.
3. GuidePageEditor App.
4. Lots of widgets.

Widget system changes:

1. Adjusted the order of the method excution (render, click, scroll and release) in AbstractWidgetGroup. Because the widget that is rendered last should have the highest priority in responding to events like click.
2. Widget adds isVisable and isActive that determine whether the Widget should render or respond to interactions. Improved rendering and computing performance in complex UI systems.
3. Fixed undefined implementation of SlotWidget to render slot in a more efficient and easy way. Remove the Scissors code.
4. Added a waitToRemoved method to delay the removal of child widgets, to allow for the removal of widgets during traversal.
5. Extended the functionality of many widgets in GTCE.

Structure:

OS:
TerminalOSWidget mainly manages the state of the App, the persistence of the App. It is also a container for Menu and Dialog. While this code is important, it is rarely need to care while develop a new App.

The Menu:
The menu system on the left of desktop, the App can register the components on the menu by override the method getMenuComponents. To customize menu components, implement the interface IMenuComponent. Code could referring to SearchComponent.

Dialog:
The Dialog system is easy to use and can be called at any time. popover, and get a response result. Currently support notification, confirmation, text input, color input and file selection. If you need to extend a new Dialog yourself, see TerminalDialogWidget.

App:

Application development needs to extend AbstractAplication. Developing an App is actually writing a WidgetGroup, but TerminalOs manages its state and supports data persistence. To implement a simple App, just override the createApp method, creating an instance and return. If you are developing a Client-Side App, you may need to override writeAction with an empty body, to avoid sending Cpackets to the server. But in createApp, you always need to return a widget even at Server-Side, and the widget can be created without adding any sub-widget. But the class should be the same as the App, that the OS can properly manage the App state. Data initialization and persistence are implemented through NBT. To develop an App, could see GuideApp, GuideEditorApp, ThemeSettingApp. Finally, please register your APP in The TerminalBuilder.

Widget:

A large number of widgets are implemented because the App and OS themselves are widget-driven. Here are some common widgets.

1. TreeListWidget for displaying the tree structure (TreeNode)
2. TextEditorWidget is used to edit multi-line text.
3. SelectorwIdget selector.
4. RectButtonWidget and CircleButtonWidget are two very useful button widgets. They have a lot of flexibility, come with animations, and can be used as the toggle button. And Click events are responded to on both the client and server.
5. DraggableScrollableWidgetGroup the Widget about drag event. Support page dragged and scroll wheel. It also has drag-and-drop event responses to child widgets that implement IDraggable. It's really powerful and easy to use. It's my favorite Widgt I've ever developed.
6. CustomPositionSizeWidget used to bind a Widget, in DraggableScrollableWidgetGroup can achieve interaction changes to the target's position and size.
7. The ColorWidget is used to set the color.
8. AnimaWidgetGroup includes an interpolator to support animation.

GuidePage:

Now start how to contribute to a GuidePage in a GuideApp.
Four apps are derived from GuideApp, showing pages of MetaItem, SimpleMachine, MultiBlockMachine and Tutorial, respectively. GuideApp has a branching system that manages which pages belong to the same section.

1. How to register items and machines in the corresponding APP? How to define the section it belongs to?
By default, all GTCEu items and machines are registered in the default section.
Items:
MetaItem.addItem(..., ...) --> default
MetaItem. addItem(..., ..., section) --> section

Machine:
GregTechAPI.registerMetaTileEntity(..., ...) --> default
GregTechAPI.RegisterMetaTileEntity(..., ..., section) --> section
(due to SimpleMachines and MultiBlockMachines use the same registration method , so the instance will be registered to the latter one while it extends MultiblockControllerBase or MetaTileEntityMultiblockPart)

Tutorial:
Unlike items and machines, you don't need code to register pages. You just need to put pages in resources/assets/gregtech/terminal/tutorials /.... The section field in the json determines which section it belongs to. It will be automatically detected and registered into the TutirialApp.
Developers who know which section their items or machines should be in, then it is best to set sections at the time of registration.

2. How to contribute guidepages for items and machines?
When you open a page that missing json, you will see the missing file "registerid.json" (e.g meta-item.scanner.json) in the title. Only need to put the corresponding json in resources/assets/gregtech/terminal/item (multibocks or simplemachines) /....

3. Localization
You can do this by using translation key for all the text while editing the page, but I know you don't like this approach. So also provides another way, if you browse the folders in resources/assets/gregtech/terminal/XXX /... en_us. Yes, you can put the pages of different languages in the corresponding folder just like the vanilla.

About the development of a GuideWidget in a GuidePage:
The existing widgets can basically meet 90% of the page writing requirements. To develop a new GuideWidget and make it available in the GuideEditor, the process is as follows:

1. For Widget, extend GuideWidget; for WidgetGroup, extend GuideWidgetGroup.
2. Since all fields in the class use Gson injection, you don't need to care how to load and save the configuration.
3. InitStream() and initFixed() (two different layouts) are called when the widget is initialized or updated.
4. getTemplate() is used to define the default values when widget referenced in the GuideEditor.
5. loadConfigurator() is used to set the configurator for the field. There are already configurators for text, Boolean, selection, multi-line text, numbers, colors, items, and fluids, which can basically meet the configuration requirements of most fields. (If you need to develop your own configurator, see the ConfiguratorWidget.)
6. Register your widget in GuidePageWidget.REGISTER_WIDGETS