Make the titles in manifest.json files purely decorative (make them not used for folder names)

[Pidgeot]

This is the improvement I would like most. I would like the title variable to have no functionality beyond their use in alphabetizing graphics packs. This way a graphics pack could have any title without causing any conflicts or problems. You can currently get around this problem by using underscores instead of spaces, but it is not the prettiest solution.

Right now the title is used to determine what the folder of the graphics pack is allowed to be named. I would like the title to not be used for that. This way we could have both a "Jolly Bastion" and "Jolly Rogers" graphics pack, or have both a "Tergel 12x" and Tergel 16x", or prefix all graphics pack with a "gfx" or "txt" for organizing packs into "ASCII" and "Graphics" sections.

A couple suggestions for making this happen:

1. Easy way: Make a new variable in the manifest.json that is used instead of the title for determining what the folder of a graphics pack is allowed to be named.

2. Hard way (bonus points): Instead of the folder name being determined by the manifest.json, make it so that the graphics pack folders can be named and renamed to whatever without it causing any problems. Implementation idea:

   • First, each graphics pack would have a unique ID line in its manifest.json.

   • Then when a user tries to change graphics pack, PyLNP would check the "DF/raw/installed_raws.txt" file to see what the unique ID of the currently installed graphics pack is.

   • Then it would scan the manifest.json files of every graphics pack to see which one matches.

     If a graphics pack has no manifest.json or does not have a unique ID in its manifest.json, then maybe it could use its folder name as an alternative. And it could indicate in the "DF/raw/installed_raws.txt" file if it's using a unique ID or a folder name for identifying the currently-installed graphics pack.

[Issue created by jecowa: 2016-08-27]
[Last updated on bitbucket: 2016-10-10]

[Comment created by jecowa: 2016-10-10]
resolved by pull request #71

[Comment created by jecowa: 2016-10-10]
Yes, thank you!

[Comment created by Pidgeot: 2016-09-04]
I believe this should be taken care of by pull request #71, yes?