mapping: allow demapping infinite/high SNR symbols

[japm48]

Description

Closes issue #326.
This simply adds the machine epsilon to no before computing the exponents. A min threshold could be used instead, but with this method differentiability is preserved. I don't think it makes sense for _eps to be user-configurable.
Given that there is a max LLR value enforced at the soft decoder side, I believe this should be enough to prevent other overflow issues.

I could add a test for this if needed (e.g.: https://gist.github.com/japm48/41bc963efec39e506c17e419c3d1e13f).

• Introduces API changes?

No.

Checklist

• Detailed description
• Added references to issues and discussions
• Added / modified documentation as needed
• Added / modified unit tests as needed
• Passes all tests
• Lint the code
• Performed a self review
• Ensure you Signed-off the commits. Required to accept contributions!
• Co-authored with someone? Add Co-authored-by: user@domain and ensure they signed off their commits too.

[japm48]

Do not merge yet, I just found another problematic case where this fix is not enough...

[japm48]

Found another culprit in the MIMO LMMSE equalizer. In this case negative no_eff values were generated, so I incremented that by 4*eps to make it work, but this time I am not so sure this is the right fix, so please review.
I also don't have any simple example demonstrating this part as I tested a full 5G chain, i.e. not easy to extract the individual relevant pieces.

[SebastianCa]

Hi @japm48,
thank you for the PR which fixes issue #326.
I have added a few small comments that should be addressed before we can merge the PR.

[japm48]

Applied all suggestions, I think it's now ready to merge, but I would leave the issue open until I figure out the potential problem in the MIMO equalizer.
BTW, I found this neat "suggest change" Github functionality, could save us some back-and-forth messaging in the future.