fix: check if it is a narcpod before trying to access getPosition

[Scoppio]

Aparently 19 years ago someone had the idea that NarcPod is a "targetable" but it has no "position" and you should not ask its position, and if you do it throws a runtime exception at you. This is... Unexpected and unwelcomed, as it implements a common API for things that can be targeted I imagined that anything that implements this API would... well.. be targetable, narcpods are not, and if you dont first check if it is not a narcpod you cannot safely check the coordinates of an attack action.

So, this PR handles that problem in the dataset logger.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 29.06%. Comparing base (a4f835c) to head (959f079).
Report is 156 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #6529      +/-   ##
============================================
+ Coverage     28.56%   29.06%   +0.50%     
- Complexity    14495    15177     +682     
============================================
  Files          2815     2835      +20     
  Lines        277388   279129    +1741     
  Branches      49002    49214     +212     
============================================
+ Hits          79226    81136    +1910     
+ Misses       193446   192619     -827     
- Partials       4716     5374     +658     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Sleet01]

I was suspicious, since INarcPods are targetable by physical attacks, the same way that Swarming Battle Armor is. See Total Warfare, pp 139 and 220.
Honestly, it should probably just return the position of the unit it's attached to, since INarcPods only get instantiated once an INarc shot hits something, and are essentially created attached to the target.
But apparently they were implemented this way on purpose? So weird.

[Sleet01]

LGTM