Replace resouce pack used in MCprep assets

[StandingPadAnimations]

Due to restrictions with Mojang's EULA, we can't actually distrbute assets using the vanilla Minecraft resource pack while also remaining GPL compliant (at least according to the Free Software Foundation in their email response: #526 (comment)). This means ideas such as #524 could go against GPL. Of course, we could have users supply textures by using the same script we use already (which assumes they own a copy of Minecraft), but it would still be best to have a default resource pack that comes with MCprep.

A good default resource pack would need to satisfy the following:

• Close to vanilla Minecraft
• Consistant updates
• Restrictions that don't conflict with GPL

The best option I have found in my research is https://github.com/Faithful-Resource-Pack/Faithful-Java-32x. While it uses its own license, the terms (proper attribution) overall should be compatible with MCprep, and are far less restrictive then Mojang's overall. While it is double the resolution of Minecraft's vanilla textures, it's still close enough for most people, and it shouldn't affect file sizes too much.

[StandingPadAnimations]

@TheDuckCow just want to know your thoughts on this proposal

[TheDuckCow]

I still feel this will make things very complicated, including new rig contributions. We could certainly try to have some kind of fallback pack, but honestly if it's not the latest pack (or if we have to put a ton of effort into pestering the owner to keep it up to date), we'll run into problems and won't work for users anyways.

I'd say the better approach would be to auto extract texturepacks from a local Minecraft install itself (which I already have a OSX-focused script to do, though would need generalizing). We could also potentially sidestep the issue by hosting asset pack downloads separately, so that users need to download the pack upon first using MCprep. If we get any notices, it could be quick and easy to remove the hosted pack files as opposed to pulling MCprep itself. We have another proposal for that whole concept here: #446

Happy to leave this one here as "on the table", but thinking prioritizing #446 and (just created) #537.