Merge branch 'release/3.0.0-beta-3' into development
Removed SteerForTarget, had marked it as Obsolete for the previous beta
Workaround for an issue appearing on Unity 4.3.4

While the shorter form works on my tests, I got a report that
DetectableObject's Transform was never being assigned on older Unity
versions.
Fixed Start method mistakenly declared as new on SteerForPoint

Also reformatted property declarations to match the style I'm using now.
No need to clear Radar's known detectable objects on load

We no longer need to hardcode clearing the known collider dictionary,
since every object will remove itself from it on disable.
Fixed comment on Radar regarding DetectableObject expectations
Reformatted SteerForSphericalObstacles, improved comments

Going to start formatting and indenting the behaviors appropriately,
hadn't originally after I added namespaces to minimize the delta, but
one can always set the diff to ignore whitespaces.
Documented why not use ?? on DetectableObject.Transform
Improved SteerForSphericalObstacles

- Previous version was using the distance to the obstacle's center, not
  to the intersection point. This means that further away but larger
  obstacles, where the intersection was closer, weren't being given as
  high an avoidance as the closer but much smaller obstacles where the
  actual intersection was further away in time.
- Avoidance strength no longer depends on the detected obstacle count but
  on how far we're from a likely intersection.
- While we still take into account the obstacles we won't collide with,
  we give them much lower avoidance priority.
Reformatted Radar to keep with the standard identation
BREAKING CHANGE: Radar no longer has an IgnoreObjects option

Are you using it? I'm not.  And it forces an extra check that while
minor is still unnecessary overhead.  You can also set entire groups of
vehicles or objects to be ignored by using a layer mask, which is much
cheaper.
BREAKING CHANGE: Removed scaled values from DetectableObject

OK, this is a big one.  It will affect how your vehicles and obstacles
are detected if they have a scale other than Vector3.one.

Starting on this commit, you *will* need to scale the radius for your
vehicles and objects manually if you change the object's scale. You will
also need to alter their current radius if the behavior is attached to an
object that you were scaling.

Put down the pitchforks and hear me out.

The scaled values seemed like a good idea when I first implemented them,
since the vehicle's radius would scale if you changed its visual scale.
Unfortunately, a side effect is that it introduced more properties that
you need to take into account when writing steering behaviors, which
could introduce errors and odd decisions, for instance:

- Do you use Radius or ScaledRadius?  Why?
- Do you really want the center scaled?
- Pop quiz! Is the SquaredRadius the square of the Radius or of the
  Scaled Radius?
- Pop quiz! What happens with the gizmo display in editor if the object
  was just deserialized, but the radius hasn't been touched? Will you be
  shown the scaled radius, the base radius, or neither?
- What if we rescale the transform without informing the vehicle?

It also has some minor quirks like not allowing easy multi-object
editing, and requiring several stub editors. Overall I've grown convinced
that the disadvantages of keeping them around outweigh the advantages.
Developers should be conscious of the changes in the object and when they
happen, and in this case, the best approach is having them perform the
change manually.

Since we're approaching a major release, it feels like this is the last
chance in quite a while to introduce a breaking change.
Updated changelog with the latest breaking changes
Added namespace to custom editors
Updating change log and read me for release
Merge branch 'release/3.0.0-beta-4'