Sybil: Index points that cause a penalty by the reason that they caused the penalty

This is the first change that I'd like to make to the Sybil attack detection tool. It elaborates upon the "Points" datastructure by giving it the ability to keep track of the reason some points were assigned. Formerly it could keep track of the reason, and the points, but there was not a way to link points assigned back to the reason they were assigned before the analysis was finished without getting them back out of the List<String>, which was cumbersome and un-uniform. It is the "baseline" of sorts for what I want to do with: #484 because it enables the sybil analysis tool to look back at the reason some points were assigned while it is still running the analysis. If a particular "constellation" of reasons and points indicates a specific type of attack(As happened in the clone attack), this allows the tool to actually spot the type of attack going on and adjust it's behavior accordingly.

Apart from that, it creates categories of "Reasons" which were recorded by moving the reasons strings from the "Analysis" section into the "Points" section as public static final String REASON_'s. Each reason string in Analysis now begins with one of these REASON_'s, so all reason "keys" follow the pattern Categorical reason + : + Details of reason. This makes them easier to search and grep through when they're stored as files and treat the categorical reason as "General" and the details as "Specific." The goal here is to enable us to spot potential constellations of unusual behavior that refers us to specific types of attacks.

In support of this, it changes the format of the sybil tool's plain-text persistence file. It is now delimited by % between points and reasons, and tab(\t) between pairs. I tested this with saved and stored analysis of the sybil file.

This simply changes the datastructure and file format to support these other operations, it doesn't attempt to implement any other changes to the sybil tool based on them.

I am aware of there being more significant overhead concerns with a sybil tool that works in this way, however my thinking is that since the sybil tool runs every few hours at most that this increase is momentary and thus acceptable.