DetectableObjects cache the transform on a public property

Previously we were just caching it on a protected _transform, but this
allows us to read it from the steering behaviors as well, without having
to cache it themselves.

I'm open for comments on how people feel about naming conventions? Should
this type of property be called Transform, CachedTransform or something
else?
Optimization: Caching rigidbody on Vehicle, using it for Mass

Just noticed because of a tangentially related forum post that I was
using the rigidbody accessor on Mass, instead of a cached value. Moved the
current cache from TicketVehicle to Vehicle.
SteerForWander no longer returns a purely lateral vector

On its previous incarnation, directly descending from the OpenSteer
implementation, SteerForWander was returning a purely lateral vector. This
means that a vehicle with no other behaviors than SteerForWander would
never actually move, just stand there.

Also added blending the random values into an accumulator, to avoid very
severe turns that made the agents look like they were having a seizure.
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.