[Items] ItemType and MaterialType

- Added two properties that existed in my old design for what should be included as part of items. Examples of how these can get used include:
-- Using the material type as a resource ID to later have the app layer create a material object, and then have skills dependent on things like a Bone material being used.
-- Using the item type as a resource ID to later have the app layer create an item type object, and then have skills require things like "doesn't work with swords, but works with maces".
[Items] [Stats] Item Stats Stored In Collection

- Instead of storing a cache of each calculated stat in an item as it's own variable, leverage the stats collection.
- Added a GetStat() method that would allow callers to look up any type of stat they want on an item.
[Items] [Materials] Builder, Factory and Complex Immutable Construction!

- This commit has some interesting pattern usage, and I'm not even sure I'm comfortable with it yet. Let me start by saying that my item class is going to get pretty complex in terms of what it's composed of, and since I want to keep a lot of the properties get-only, it makes it tricky to get all of that information into the class.
- This commit also added an IMaterial that I hinted at in a previous commit... This is just an easy way to start tackling a problem I think is going to get really nasty later on when I start adding more and more to the item class (which, of course, I need to keep an eye on in terms of complexity).
- I decided that I'd implement a builder pattern (and because I'm trying to take programming to interfaces to an extreme here, if you haven't noticed) I have an interface on this too.
-- A caller would say Item.Builder.Create() to get a new IItemBuilder instance.
-- The caller can use this new instance to assign their necessary resource loaders, so in this case, WithMaterialFactory().
-- The caller can finally say Build() with some parameters that will be specific to the new item instance.
--- NOTE: I played around with how I felt about the IEnchantmentCalculator... this thing will eventually have scope about the game world (i.e time of day, weather, current map, players, etc...) and I'm still undecided as to whether I want to associate it with the builder, or with the instance of the item I'm making... So I left it where it was. Easy enough to change later, I think.
-- The builder itself is passed into the constructor of the item (mind blowing, right?) so that it can access the factories to help load up the resources it needs.
- Few of my concerns/thoughts right now:
-- Not sure how I feel about that whole design... I've never done something like this before, but it actually seemed to work pretty well.
-- Need to nail down naming...
--- I use Create() to make an item instance to meet an interface
--- My only factory used Load() to map an ID to an interface instance.
--- I use Build() on my only builder to make a new instance after everything is set properly.
--- Should I follow this trend? Are some of these actually the same thing?