Added dual-license notice (Apache-2.0 and along with GPL-2.0)

[AkarshSahlot]

Changes I have done:
This PR updates the LICENSE file inside p4c to explicitly:

1. State that p4c is primarily apache2.0 licensed
2. List all gpl2 only files(with full license text)
3. Add warnings about license incompatibility
4. Include SPDX identifier (Apache-2.0 WITH GPL-2.0-only-exception) so that users doesn't get confuse project as pure Apache, ignoring GPL restrictions.

Previously Behavior:
The repository only listed Apache-2.0 in the top-level LICENSE file, which make users think it's purely apache
gpl2-only files existed but were not clearly documented , which has a risk of:

• Unintentional license violations when combining code
• Misrepresentation of the project’s licensing (GitHub’s API showed only Apache-2.0)

Why This Important for us to do:
Prevents accidental mixing of incompatible licenses.
Increased Transparency, Users/tools can now identify GPL-2.0-only files at a glance.
Now it follows spdx standards for multi-license projects.

Verification
All listed GPL files exist (./backends/ebpf/tests/ptf/*.py)
License texts are verbatim from official sources
Compliance notes warn against static linking/binary distribution
I verified them locally
This small addition solves big legal/automation headaches!
Fixes #666
/cc @jafingerhut @mbudiu-bfn Could you please review this license clarification?

[jafingerhut]

"Fixes #666" does not appear correct, as that issue appears unrelated to these changes.

While Mihai Budiu was very active in contributing to this repository in the past, he has moved on to other work, and it is best not best to ping him directly unless there is some historical technical question about p4c that only he might know.

[jafingerhut]

@AkarshSahlot I have been investigating what we should be doing long term to the p4lang repositories (this one, and all of the others) to get our copyrights and licenses in a better state, at the suggestion of a software license specialist at the Linux Foundation who reviewed the current state of our repositories in Nov 2024.

One possibility they mentioned, and that I have been trying most recently on a smaller repository to see how much trouble it is, is to use the suggestions and tools of the REUSE project on https://github.com/p4lang/tutorials. You can see a sample PR here: p4lang/tutorials#674

You can read more about the REUSE project here: https://reuse.software/tutorial/

Note: BEFORE we make all of those changes on much larger repositories like p4c, I want to review these ideas with a larger part of the P4 community, and also with an intellectual property lawyer, perhaps one from the Linux Foundation. The goal would be to have a set of requirements written down and maintained for all p4lang repositories, agreed upon by all the stakeholders, before we make too many changes.