Re-claiming efficient 8bit computations in CosetLeadersMatFFE

[osj1961]

Inside CosetLeadersMatFFE there is an if-elif-else construct that divies up the actual work based on whether the code is over GF(2), an "ok8" field that can be represented in 8-bits, or a generic GF(q) w/ q>256. In the ok8 case certain cosets were getting missed leading to a returned list with unbound entries. I made a local (to guava) version of the function called GuavaCosetLeadersMatFFE and commented out the ok8 branch (i.e. let even smallish fields be handled by the general case).
This fixes the errors in CoveringRadius and SyndromeTable, but loses some of the speedup previously achieved for codes over the ok8 fields.
So this "fix" must be considered temporary and reverted once a fix can be found for the CosetLeadersMatFFE method in gap/lib/listcoef.gi