Optimize guide line algorithm

[Technius]

The guide line algorithm is too slow; there's a noticeable FPS loss after creating a movement order to somewhere far from the ship. We should probably either cache the line (by dynamically creating and adding a node) or make the algo faster.

[Technius]

Another way to do it is to draw all the lines at once instead of calling draw_line multiple times, which is expensive. Maybe we can combine draw_arc and draw_line?

[TropicMango]

I have changed the way the indicator path is being calculated, it now is calculated when you first change the click, and that is now stored into a list. However the guide line is still being up dated when you "end turn", which was not expected (i was thinking that the path will just stay at the original location while the ship moved along it)

[Technius]

Looks like you committed to godot3 branch by accident. I'll merge your commit into master.

[Technius]

The performance is much better, but it's still bad. On my desktop, CPU usage went from 144% to 40%, but this is just for two lines! I think we need to come up with a few more changes to fix the problem.

[Technius]

I moved the todo list from #8 to here, since #8 is "good enough" to merge for now.

TODO (in no particular order):

• If traveling in a straight line, only add the endpoints. We can tell if we're in a straight line if the angle difference stays at zero.
• Use draw_polyline instead of looping over the points and calling draw_line individually. (Need help here: https://imgur.com/a/3PxiA)
• Create a physics helper class to serve as a "source of truth" for all the physics things (like movement code, angle conversions, etc.). This is so that if we change the movement logic, we won't have to modify both the movement line logic and the entity movement logic.
• Recalculating the line is expensive (can take up to 50% of frame time), so we need to figure out how to not do it on every frame. (Update: line is only recalculated when the player position or target changes, but it's still recalculated when the player moves).
• In recalculate_move_approx_line, we can probably store pow(_player.speed * line_draw_rate, 2) in a constant instead of recalculating it on every iteration.
• Maybe abstract the approximation logic so that we can reuse it for AI?
• Make target a variable in MoveTargetIndicator