Experimental: Implement Expandability for ListBoxFrame.

[bearU369]

Problem While working on with #23, I had issues with the ListBoxFrame being restricted to only display a single text frame and each item only hold 1 string variable that is handled for listeners. These restrictions make it difficult to implement the map-icon frame, player-count frame, map-name frame, and few Strings and Integer for keeping map information without re-reading back the map every time I scroll through the list. The hacky solution for it is by duplicating the ListBoxFrame with its properties modified to handle for that specific task.

However, this implementation made me ask myself whether how this will be maintained. Considering that ListBoxFrame and the duplicate aims to do the same thing, to display items and to interact with them, I felt that ListBoxFrame would have more use-case than the duplicate copy of it since there's no point to expand on it that needs icons, counters, and few variables for map properties. (that's how hard-coded it is)

Solution Instead of making duplicate copies of ListBox, I looked over on how the SingleStringFrame and String variables being handled in the class before the conclusion of this implementation:

AbstractListItemProperty -- handles the String variable for handlers, and any kinds of variables to allow the developers to store any data for different purposes. AbstractListItemDisplay -- handles the UIFrames to display on ListBoxFrame and allow the developers to decorate that item visually. It create a "parent" frame where players would able to select it alongside where multiple UIFrames would anchored to. ListItemEnum -- the enum that indicates the type of ListBoxFrame's items. This is where both ItemProperty and ItemDisplay interact and identify with each other. If any ItemDisplay is not compatible with the selected ItemProperty, the ItemDisplay would be replaced with another ItemDisplay that is built to handle that ItemProperty

In theory, if a developer wanted to implement a different kind of List item, they would need to add 1 enum type in ListItemEnum, 2 classes that inherits both ItemProperty and ItemDisplay, and declaring those classes in both abstract classes' createFromType method. And that's without touching the ListBoxFrame! The ListBoxFrame should be smart enough to show which is the right UIFrames to display for that specific item. It should be possible to add variety kinds of ItemProperty into the same ListBoxFrame and it would display the item just right.

This pull request should remain on draft because it was never tested properly with different/mixed ItemProperties. The ListBoxFrame is currently used for only texts and so far there are no items unique from just texts. (except the map item that are not implemented yet)

[bearU369]

Tinkered further with the ListBox and set up a test branch to create test ItemProperty/Display for showcasing the effect. I'm quite happy with the result.

[bearU369]

With the previous PR merged, I replaced the MapListBoxFrame into ItemProperty and ItemDisplay as the ListBoxFrame is built to be dynamic as possible when it comes to variety kinds of item properties being mixed into a one whole list.