[B+C] Implement World.getEntities(Location, x, y, z). Adds BUKKIT-3868

## The Issue

There is currently an Entity.getNearbyEntities() method, but no way to perform a similar check on an arbitrary Location without an Entity.

## Justification for this PR

This PR adds the Location.getNearbyEntities method requested in BUKKIT-3868, as well as a World.getEntities(Location, x, y, z) method that backs it. These additional utility methods provide a way for developers to efficiently query for entities within a given area, without needing a source Entity.

## PR Breakdown

### Bukkit

Add Location.getNearbyEntities(double x, double y, double z) and World.getEntities(Location center, double x, double y, double z)

### CraftBukkit

CraftWorld implements getEntities similarly to CraftEntity, except it passes in a null source Entity (given current NMS code, this is safe, the entity parameter is only used with "==" to filter out the source entity) and it creates an AABB rather than using a modified Entity BB.

## Testing Results and Materials

A test plugin can be found here:

https://github.com/NathanWolf/Bukkit-Unit-Tests/tree/Fix-BUKKIT-3868
http://mine.elmakers.com/share/Test-Fix-BUKKIT-3868.jar

This plugin will search for entities at your target block (block under cursor) when you swing (left-click) a stick or blaze rod.

A stick will check within 8 blocks, a blaze rod within 64. It will print a list of entity counts by type in the area, and can be used to validate that the correct entities are found.

## Relevant PR(s)

B-1068: https://github.com/Bukkit/Bukkit/pull/1068 - Associated Bukkit PR

## JIRA Ticket
https://bukkit.atlassian.net/browse/BUKKIT-3868
So should I leave it? My email notifications don't gel with what's on this page now :)

Those methods were actually a special request by @aikar , who had them in a similar PR (or maybe just a private lib) of his own. I think it's a handy feature- my impression was the deprecated one was only deprecated due to a bad name - "ByClass" being used for a plural "classes" parameter list, favoring the singular version taking only one class.

I may be missing some nuance here, though.