Added basic range indicator to target list.

Partially addresses RemoteTechnologiesGroup/RemoteTech#2. Indicator does not yet support multiple omni bonus or root range model.

Also renamed IAntenna.Radians to IAntenna.CosAngle, to prevent future programming errors.
Merge pull request #30 from Starstrider42/rangefinder

Rangefinder
First draft for TargetInfoPopup
merge
Moved from RT2 to RT Folder
Resolved conflict
commented strastriders code
Merge remote-tracking branch 'origin/master' into rangefinder
Switched to more meaningful variable names.

Replaced names like `a` and `b` with semantic names, and updated names from underscore to camel case.

Also reversed order of arguments for RangeModel.GetContextRange, to bring it more in line with the RangeModelExtensions.IsTargeting* functions.
Fixed bug with active vessels.

Some RT functions recognized active vessels, others did not. Now everything is consistent.
Replaced isTargetingPlanet with more general function.

The function uses exactly the same logic as isTargetingPlanet, but no longer demands that the target be a celestial body nor that the satellite being contacted must be found in the target's SoI.
Cones now display for any target.

Orientation vector `up` switched from dish target to camera focus. I'm assuming that the reason `up` was inferred from a celestial body in the first place was for forward compatibility with inclined planets.

Fixes RemoteTechnologiesGroup/RemoteTech#13, fixes
RemoteTechnologiesGroup/RemoteTech#14.
Some more name refactoring.
Protection against NREs.

`Vector3.up` appears to be the default value of `CelestialBody.transform.up` at present, so this change should have no effect visible to the user.
More style cleanup.

Renamed a few variables that @erendrake spotted. Factored `ISatellite.this[]`. Renamed RangeModel functions to upper CamelCase, in keeping with [C# conventions](http://msdn.microsoft.com/en-us/library/ff926074.aspx).
Moved `GetPositionFromGuid()` to `NetworkManager`.

Just realized that RangeModelExtensions is meant to have, yes, extension methods. `GetPositionFromGuid()` doesn't qualify, but it serves a similar purpose to a few other `NetworkManager` methods.

Throwing an exception on invalid input is not standard for RemoteTech methods, but since Vector3d is not nullable I can't think of a good way to handle the error internally.
Merge pull request #230 from Starstrider42/cone-fix

Consistent cones
Merge pull request #249 from RemoteTechnologiesGroup/master

1.6 update
Draft update
Final commit of the rangefinder