ItemData instance creation from XML

[fennifith]

This will require extensive modifications to the CLI (or even just replacing it completely - see #36), but I essentially want the XML to be "inflated" similarly to a layout file, where the entire package name of each class is provided in the tag. Sub-tags, like "contributor" or "link" would be unaffected (or even replaced with an ambiguous name, like "item"), and would simply be passed to the constructor of each "main" item (or I could just continue passing an instance of the parser like I am now). This would allow users to add their own functionality to the about screen instead of only being able to override layout files.

[fennifith]

Rather than creating an ambiguous "item" tag inside a class tag, it might be more productive to make another subclass - ListInfoData<T> - which accepts two layout resources (InfoData accepts one for the item itself, the second is for the nested RV that will exist inside of the item). As such, it will also contain two binding methods - bind(Context, ViewHolder) inherited from InfoData and bindItem(Context, ViewHolder, T) to bind the nested RecyclerViews items, which will be called from the item class (T in relation to the method call, ex: in ContributorsItemData, T would be an instance of ContributorItemData).

This is going to be confusing and stupid. Depending on how things go I may also make a subclass for the nested items, making the list info subclass ListInfoData<T extends ListItemData> or something.

[fennifith]

On second thought, I was right. This was confusing and stupid. It is better to go with a recursive method of nesting ItemDatas instead of having different classes for items that might have items inside them.