Replace occurrences of scapy with pktmanip for "packet manipulation module"

[jafingerhut]

except those few places where scapy is actually a requirement, e.g. in the code that actually imports Scapy as the selected packet manipulation module.

It is expected that these PRs are approved and merged before this one:

• Add docs on using pmm (packet manipulation module) bf_pktpy, and option to select pmm by env variable #213

[jafingerhut]

This has been rebased to be "on top of" the changes proposed in PR #213

That one should be reviewed before paying attention to this one, which I will soon put in draft mode.

The purpose of these changes is to avoid using the name 'scapy' in the "production" part of the ptf package, i.e. the files that are imported when you run ptf or do import ptf, except in the very few places where the user says they want to use Scapy as their ptf packet manipulation module. Before these changes, there were several places where the name 'scapy' was used as an alias for the module 'ptf.packet', which is misleading if the user selects a non-scapy package as their packet manipulation module.

If they say they want bf-pktpy as their packet manipulation module, then except for two if-then-else branches that are never taken, there is no mention of the word 'scapy' in the source.

These changes leave explicit uses of scapy in ptf test programs, that are not part of the production ptf code, in these directories:

• ptf_nn/
• utests/
• .github/workflows/
• src/ptf/packet_scapy.py - This file is part of the production ptf package, but it is only if the user selects scapy as their packet manipulation module. This file's contents are completely ignored if the user selects bf-pktpy as their packet manipulation module.