Add awake flag for bats. Adds BUKKIT-5606
Change YamlConfiguration encoding styles.

On JVMs with UTF-8 default encoding, this commit has no change in behavior.

On JVMs with ascii default encoding (like some minimal linux installa-
tions), this commit now uses UTF-8 for YamlConfiguration operations.
Because all ascii is valid UTF-8, there is no feature degradation or data
loss during the transition.

On JVMs with any non-unicode but ascii-compliant encoding, this commit now
forces YamlConfiguration to escape special characters when writing to
files, effectively rendering the encoding to be plain ascii. Any affected
file will now be able to migrate to UTF-8 in the future without data-loss
or explicit conversion. When reading files, YamlConfiguration will use the
system default encoding to handle any incoming non-utf8 data, with the
expectation that any newly written file is still compliant with the
system's default encoding.

On JVMs with any non-unicode, but ascii-incompliant encoding (this may be
the case for some Eastern character sets on Windows systems), this change
is breaking, but is justified in claim that these systems would otherwise
be unable to read YamlConfiguration for implementation dependent settings
or from plugins themselves. For these systems, all uses of the encoding
will be forced to use UTF-8 in all cases, and is effectively treated as if
it was configured to be UTF-8 by default.

On JVMs with unicode encoding of UTF-16 or UTF-32, the ability to load any
configurations from almost any source prior to this change would have been
unfeasible, if not impossible. As of this change, however, these systems
now behave as expected when writing or reading files. However, when
reading from any plugin jar, UTF-8 will be used, matching a super-majority
of plugin developer base and requirements for the plugin.yml.

Plugin developers may now mark their plugin as UTF-8 compliant, as
documented in the PluginDescriptionFile class. This change will cause the
appropriate APIs in JavaPlugin to ignore any system default encoding,
instead using a Reader with the UTF-8 encoding, effectively rendering the
jar system independent. This does not affect the aformentioned JVM
settings for reading and writing files.

To coincide with these changes, YamlConfiguration methods that utilize a
stream are now deprecated to encourage use of a more strict denotation.
File methods carry system-specific behaviors to prevent unncessary data
loss during the transitional phase, while Reader methods are now provided
that have a very well-defined encoder behavior. For the transition from
InputStream methods to Reader methods, an API has been added to JavaPlugin
to provide a Reader that matches the previous behavior as well as
compliance to the UTF-8 flag in the PluginDescriptionFile.

Addresses BUKKIT-314, BUKKIT-1466, BUKKIT-3377
Updated version to 1.7.9-R0.1 in pom.xml for Beta.
Updated version to 1.7.9-R0.2-SNAPSHOT for development towards next release.
Updated version to 1.7.9-R0.2 in pom.xml for Beta.
Updated version to 1.7.9-R0.3-SNAPSHOT for development towards next release.
Rewrite BukkitMirrorTest
Fix failing BukkitMirrorTest
Add damage modifier API in EntityDamageEvent. Adds BUKKIT-347, BUKKIT-4104

This commit adds API for the enchantment, armor, potion and other
modifications to damage done to an entity. These damage modifiers are each
editable editable via a getter and a setter. This addition allows for more
accurate modification and monitoring of damage done to/by an entity, as it
displays the final damage done as well.
Replace getOnlinePlayers to provide a view. Adds BUKKIT-5668
Update Bukkit for Minecraft 1.7.10
Pulling all pending Bukkit-JavaDoc changes
Recalculate damage modifiers in event for old method. Fixes BUKKIT-5681

When we added the new API in EntityDamageEvent to give control over the
various things that modify the final damage done we caused a change in
behavior for users of the old #setDamage(double) method. Before changing
the damage would happen before the modifiers were calculated so they would
be based on the final damage value from the event. Now they are calculated
at the beginning so changing the damage does not change the modifiers.

To allow the old style and the new to coexist we now expose the vanilla
modifer calculations to the event in the form of Function objects. These
are used in #setDamage(double) to calculate the difference in the modifier
between the old damage and the new and apply this difference to the current
modifier. The difference is between the vanilla values for both damage
values and is applied on top of the event's modifier value as this should
make old and new API usage work together in a way that isn't surprising.