`model_maybe_fixup_subsys_path` is beyond borked

And honestly I'm not sure how to fix it. Here's an exerpt, this is after loading a model it goes through all the path which have a valid subsystem as their 'parent'

```
// ensure that the subsys path is at least SUBSYS_PATH_DIST from the
// second last to last point.
void model_maybe_fixup_subsys_path(polymodel *pm, int path_num)
{
...

model_path *mp;
mp = &pm->paths[path_num];

...

index_1 = 1;
index_2 = 0;

v1 = &mp->verts[index_1].pos;
v2 = &mp->verts[index_2].pos;

dist = vm_vec_dist(v1, v2);
if (dist < (SUBSYS_PATH_DIST - 10))
{
vm_vec_normalized_dir(&dir, v2, v1);
vm_vec_scale_add(v2, v1, &dir, SUBSYS_PATH_DIST);
}
}
```

```
// SUBSYS_PATH_DIST is used as the distance that a subsystem path should terminate from the actual
// subsystem. We don't want to rely on the model path points for this, since we may need to be
// changed.
#define SUBSYS_PATH_DIST 500.0f
```

Basically the 0th point, is pushed away from the 1st point, until it's at least 500 meters away. Even setting aside why tf this is being done, paths start away from the ship and go *towards* the ship. So is 0 and 1 supposed to be the "last/second-to-last"?? If this is meant to be affecting the distance the path terminates from the subsystem (even making the assumption the last index point is at the subsystem's position) it should be `num_points - 1` and `num_points - 2`, and for that matter the rest of the point too, since we're potentially introducing a 'kink' in the path by waggling around a point in the middle.

Additionally, this is completely invalid for fighterbay paths, yet modeler's intuitively expect to put the fighterbay subsystem as the parent to their bay paths, making (just one of) those paths subject to this manipulation. I'm not sure how, or if, destructible fighterbays work, but that might *require* that they put the fighterbay as the parent.