Bugfix: Refactor packet scoring to use airtime

[ViezeVingertjes]

Replaces the packetScoreInt method with packetScoreByAirtime, which penalizes based on time-on-air instead of packet length.

Before:
Fixed SF=10, byte-based penalty - mistuned delays and more collisions.

After:
Uses runtime SF and airtime - correct delays, fewer collisions, faster forwards.

[ripplebiz]

The packet 'scoring' is currently not used. It is tied to the 'rxdelay' config, which we had a lot of problems with in the very early days of MeshCore. I'm still hoping to retry the rxdelay mechanism at some point, because what it tries to do is choose strong paths (ie. with potentially more hops) over paths with weak links (but fewer hops). Now that denser meshes are actually out there, ie. more paths to choose from, this mechanism 'should' be useful.

This change, however, I'm not entirely sure it's really any different, ie. having penalty based on packet length vs time-on-air. Scores are relative, ie. scores compared to other scores. Packet length and time on air are roughly linear, so am not convinced (from just reading the code) that it is significantly different (or better?)

[ViezeVingertjes]

This change, however, I'm not entirely sure it's really any different

You could replace the whole old logic with a single random delay and it would have been just as incorrect in most cases, so it should make a difference, while testing it did not even look remotely close, but i am not on SF10 te begin with. I don't think the implementation is a lot different personally though... i used getEstAirtimeFor as it was available, but that still is somewhat based on the packet length.