Initial commit of requirements for extending global helper functions

[Alan-Jowett]

Description

This pull request adds a comprehensive requirements document for supporting global helper functions from external drivers in the eBPF for Windows ecosystem. The document outlines the limitations of the current system, proposes requirements for name-based global helper registration, and details backward compatibility and extensibility goals.

Requirements and system design:

• Introduces support for external drivers to register global helper functions using descriptive names, eliminating the need for centralized numeric ID management and coordination.
• Specifies that each eBPF program will maintain its own stable mapping of global helper names to IDs, with resolution occurring at program load time for both core and external helpers.
• Ensures backward compatibility by allowing mixed usage of named and numeric global helpers, with no required changes to existing drivers or compiled programs.

Developer experience and ecosystem growth:

• Enables third-party drivers to independently expose global helpers, with the system detecting and rejecting name conflicts at registration time, and providing clear diagnostics for developers.
• Establishes success criteria for driver independence, developer experience, system stability, and future ecosystem growth, including support for multiple providers and extensibility for advanced scenarios.

Testing

N/A

Documentation

Yes

Installation

No

[dthaler]

After some thought, I am not sure I agree with lines 26 or 27 and suggest we should delete them.
Specifically, lines 26-27 contradict line 25 by requiring coordination to avoid name conflicts. Hence I agree with line 25 and that means I disagree with 26-27.

Suggested change

	- The system **MUST** reject registration attempts when multiple drivers try to register helper functions with the same name
	- Helper function names **MUST** be globally unique across all registered providers

I believe Linux has no such restriction (so says copilot anyway), and BTF IDs provide a mechanism where each loadable kernel module could have helper functions with the same name. For example, the situation can arise in two example cases:

1. if a third-party extension implements a helper function that exists on Linux, because ebpfcore and netebpfext don't. Then in a later release ebpfcore wants to implement the standard helper function. Lines 26-27 would prevent that.
2. if two third parties independently want to implement a helper function that exists on Linux, because ebpfcore and netebpfext don't. Neither want to depend on the other (perhaps they're competitors). Lines 26-27 would prevent that and require coordination between them which contradicts line 25.