Allowing radars to be have a configurable queue, max update per tick

This will be useful if you want to configure some radar queues
differently, for instance setting high-priority agents on a separate
queue with a higher limit of radars updated per tick.
Added AcceptableDistance to SteerForPursuit
EXPERIMENTAL OPTIMIZATION: Removing allocations on Radar

I've limited the number of objects a radar can detect in order to be able
to pre-allocate an array for them.  I'm also caching the detectable
objects or vehicles associated with a collider, if any, instead of
querying for them continually.

On a test with 100 boids running around, plus a few other agents, 50 of
which are considered every tick, the  FilterDetect method dropped from
taking about 1ms and allocating 32k to taking 0.2ms and doing no
allocations for the most part (after the collider's transforms have been
cached).

The current approach is experimental, and might not be ideal, since I
have a dictionary of transforms as a static value which will need to be
reset when a scene is loaded (oh, to have a OnSceneIsUnloaded method!),
but it'll do for testing.
Made Steering.CalculateForce abstract, no need for it to be virtual
SteerForNeighbor.CalculateNeighborContribution is now abstract

That way we make sure that any descendants are forced to implement it.
Changed Radar.DetectLimit into PreAllocateSize, Arrays into List<T>

Doing a generic list with a nice pre-allocated chunk affords us the same
efficiency as allocating an array, so there's no need for the artificial
length limitation. See commit f3c5ee5 for performance numbers.
Caching Vehicle's GameObject, since it can be queried by the steerings
Changed Radar.Vehicles,Obstacles to List<T>, optimized SteerForNeighbors

Using a list instead of a IEnumerable allows us to access the list by
index instead of using an enumerator, which in turn halves the number of
KB allocated per call and also reduces the total execution time on a test
with 100 boids.

Also checking if the GameObject has not been destroyed since we added it
to the list.
TickedVehicle improvements

- Changed iterator for a loop when both calculating forces and when going
  over the post-processing forces on TickedVehicle.  Combined with the
  previous changes, this has eliminated allocations on a normal cycle of
  CalculateForces.
- Standarizing away from custom delegates to Action<T>

Still need to review TickedQueue.Update(), which seems to allocate
7K every frame.
Adding a custom TicketPriorityQueue to reduce allocations

With this library, we have reduced allocations on a 100 agent scene from
7.2K per frame to 3.2K.  Most of these come from the radar, where Unity's
OverlapSphere returns an array, and are likely unavoidable if we are going
to be querying for tightly grouped neighbors continually.

Make sure you don't keep two copies of the TickedPriorityQueue dll in
your project.
TickedVehicles now have a configurable MaxUpdatePerTick
Combining two Radar.FilterDetected loops into one

This cuts filtering time per frame on a 100-boid sample by about 30%.
Would probably have seen it when I was working on 865825a and f3c5ee5 if
I wasn't in such a refactoring frenzy.
RandomizePosition changes

- Renamed to RandomizeStartPosition for clarity.
- Radius is now a Vector3 for extra control.
- BUGFIX: Radius was being used twice.
Optimization: RecordCalculatedVelocity should use cached transform
Trivial SteerForForward behavior, will work as an example
Renamed RecordCalculatedVelocity -> UpdateOrientationVelocity

The previous name didn't actually make as much sense, and wasn't really
clearing up what the method did.
SteerForSphericalObstacleAvoidance should use the future desired position

Now that the behavior is a post-processing one, we don't need to estimate
based on the vehicle's current position and can do so based on its future
desired position, which should give us a better idea of what the vehicle
is trying to do so we can correct it.
Added SteerForSphericalObstacleRepulsion

I'm not happy with the results I get out of the currently existing
SteerForSphericalObstacleAvoidance when we have multiple obstacles in
relatively close proximity.

New experimental spherical obstacle avoidance method. Unlike the previous
one, Repulsion takes into account more than one obstacle and behaves in
a rather different manner. See the remarks on the behavior comments for
an algorithm description.
Updated changelog for beta 3
Removed unused variable.