Add !details

Re-wrote the command to run entirely on the server side (aside from returning the preexisting !data field).

Targets pokemon and returns !data + Dex number, height, weight (the BP of LK/GK), dex color, egg groups, and all evolutions (and the level at which they are first obtainable).

Maintains the "spell check" feature of !data, but returns an error message if an item, move, ability, or nature is targeted. Includes help command, an error message if you don't specify a target, and an error message if it's too far beyond correct spelling to be read.

Now before I try to justify why all the return fields are in there, I'd like to point out that this command is separate from the !data command for the reason that most of this information is assumed to be less useful, and else often needed to be accessed. Since much of the information is already situational, having extra, unnecessary data returned is not nearly as much of an issue, since it's unlikely anyone will be trying to sort through any of these fields in a hurry.

Dex number is important because it can allow the user to infer the generation number of the pokemon, which might be useful in older gens if they are not sure. While perhaps not the most important, it looks best visually as the first field and comes close to lining up with the new Tier field, giving it more of a familiar feel since that's where dex number used to be stored. 

Height is the next field and is currently completely useless. I made an argument for why it should be included on the pull request on the client side, but I'll paraphrase again here. The command looks weird without including height, and one of the reasons for that is every other similar command lists both height and weight (and always in that order). While height might not have any baring now, a lot of the information in this command is more applicable to various OMs, and I don't find it unreasonable for an OM to utilize height data at some point. Personally I believe the only reason that has never even been discussed before is because information like height and weight are not very accessible for team building, making the meta require too much research to be practical. Giving out all the information that exists like this lets the community decide how they want to use it, not just supply it when there becomes a need for it.

Weight is a pretty obvious one and includes the commonly requests Lk/GK base power along with it. I include the exact number for similar reason to what I mentioned in the height paragraph. 

Dex color is immediately relevant to making monocolor teams, especially for non-obvious ones like Rotom-w being red, or how Charmander is red but Buizel is brown despite being the same color of orange. 

Egg groups might seem outclassed by the !learn command since that gives much more detained information, but egg groups can still hold indirect use in a similar way by giving people some idea on what moves might be shared. Also I personally feel that a mono-egg-group meta would be really interesting so I'll just leave that out there.

Last field is evolution. Originally I just wanted to include the number at which things evolve since that's what you want to know usually, but it was pointed out to me that some split evolutions (like slowpoke) don't happen at the same level, and the only way to show that level difference is to label which poke it applies to. This can be relevant to level based metas, but more honestly I put this field in because I here people ask for this one all the time.

Information not included: 
-Gender ratio: even my imagination couldn't think of any possible use for this.
-pre Evolutions: I feel that a majority of showdown users know the evolutionary trees pretty well, and because it can be a somewhat large field felt it was not worth including.


Notes on GUI: 

In this image I'm using just about the smallest screen resolution for a monitor out there, so this is showing what a "worst case" GUI might look like on laptops or similar devices. For most resolutions this command returns as just 2 lines, !data + the string of details information.

.join("&nbsp;|&ThickSpace;") is used to combine the fields. I wanted to use a few cases of &nbsp; to help ensure that the fields stay grouped together with their data. &ThickSpace; is used because in the battle rooms the spaces from .join(" | ") were removed automatically by Showdown to help compact the return line. This would have been a nice feature and would improve the look in the battle room is it also removed &nbsp;, but since it doesn't I added in &ThickSpace; on the other side to ensure that the .join() retains symmetry even in the battle rooms.

Obviously it's very difficult for me to test on every screen resolution on my own, so if somebody encounters a GUI problem that I did not see, post about it here and I'll attempt to correct it.


Known errors:

"!details metronome" returns an error message stating that metronome is just an item. This isn't a problem in any way, but I thought I'd point it out.
"!details eevee" returns some incorrect information about the level at which Eevee evolves into it's different Eeveelutions. I will be making another pull request to correct this shortly.

In the attached image the error message says "showding" instead of "showing", I just fixed that and it's not that win in the code now.
![ss 2014-06-19 at 12 29 52](https://cloud.githubusercontent.com/assets/7889474/3333152/7a992900-f7ef-11e3-9879-2d3975f043cf.jpg)

I've since removed a few cases the &nbsp, but the way I've set up in the .join() I feel is really necessary to insure that if it wraps around a line does not begin with "| ". I tried to explain in the original pull description, that because of the way battle rooms compact spaces, using a standard space character makes the .join() look lopsided. using &nbsp on both sides would be horrible because that would make it so that it <em>only</em> ever wraps the text around by breaking one of the data fields in half, which is what I'm generally trying to avoid.