feat: Support for using Ansible playbooks for installing model components

[sdelliot]

Current State

Currently, some Model Components may require additional data to be downloaded (e.g., VM resources, etc.) that cannot or should not be stored within the MC repo package. In this case, the Model Components can have an INSTALL file, which can be any executable script (as denoted by a shebang line). See: Model Component INSTALL file.

This PR enables using Ansible playbooks in lieu of using a bash-based script.

Primary Benefits

There are several primary motivators for this change:

1. Idempotence - By design, it is significantly easier to design Ansible playbooks that can be run multiple times without changing the final state. Specifically, this is necessary when installation fails and needs to be re-run. While other scripts can have this property, Ansible makes it significantly easier to do so.
2. Readability - INSTALL files that are written with Shell scripts are significantly harder to read/understand than Ansible-based YAML. This not only impacts maintainability, but also the security as reviewing shell code for issues is more difficult.
3. Pulling Cached Files - Downloading files and creating VM Resources or images each time FIREWHEEL is installed is time consuming and, in the case of offline installations, impractical. The common solution for this is to perform this action once and cache the resulting files. By using Ansible, FIREWHEEL can provide a few common ways to retrieve these cached files. When combined with the Idempotence of Ansible scripts, this will further reduce installation errors and speed new installs.

Key Changes

1. A new top-level FIREWHEEL config option called ansible where users can add other values (URLs, API Keys, etc.) for getting the various cached files.
2. New Ansible playbooks that support caching from Amazon S3 buckets, Git repositories, and file servers.
3. Modifications to the model_component_install.py to check and see if the INSTALL file has a shebang, and if not, we check if it is a directory. At this point, we check for a tasks.yml and vars.yml to indicate that it is a proper Ansible structure. If it is, then we will use ansible-runner to execute the the tasks, which get included into main.yml.
4. Updated documentation which explains, in detail, the new structure.

NOTE: Despite this large feature, this is not a breaking change as the current functionality still works and will be deprecated/removed in a future release.

[gregjacobus]

just a few spelling things for now. Still getting through some more architecture review, but so far, looking really good