Support extra provision builder generated component files

[yanchengnv]

Fixes # .

Description

The Flare Provision system allows any number of Builders to support certain functions (e.g. Confidential Computing), and some extra resources may be needed in run time for the functions to work properly. This PR implements this requirement.

The design of the Provision system encourages builders to be self-contained and independent of each other. When a builder needs to add extra resources, it should create its own config file for these resources, instead of adding them to config files managed by other builders.

At the start of Flare process (SP, SJ, CP, CJ), appropriate builder-generated config files will be loaded. Note that not all such files are for all processes: some are for parent process only, some are for job processes only, and some are for both.

This PR defines the naming convention for builder-generated resource config files:

• <builder_name>__resources.json: for both parent and job processes;
• <builder_name>__p_resources.json: for parent process only;
• <builder_name>__j_resources.json: for job process only.

When generating a config file, the builder must decide which process(es) the resources are for and name the file properly.
The builder also must decide where to place the config file in the startup kit: in the "startup" folder or in the "local" folder. Files in the "startup" folder are signed and cannot be tampered with; whereas files in the "local" folder can be modified by the site admin.

The naming convention must be strictly followed; otherwise the builder-generated config files won't be loaded during run time.

The format of the builder-generated config file is defined by the builder - it can define any properties needed by any components. HOWEVER, if it needs to add components, then the config file must have a "components" section, and components must be added to this section! This also the way that existing resources files use.

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Quick tests passed locally by running ./runtest.sh.
• In-line docstrings updated.
• Documentation updated.

[YuanTingHsieh]

LGTM

[YuanTingHsieh]

/build