Feature/handle local record type markup

[jdschleicher]

Motivation and Context

Before this update, faker values associated with picklist, dependent picklists, and multipicklists were based upon each available value found in the field's xml markup.

In the scenario of a real Salesforce org, these fields and associated options in picklist values are adjustable through the use of Record Types.

This update introduces logic to parse an object's expected "recordTypes" directory. If one exists in the source code for an object, a record type to available picklist values map will be used to adjust what shows up as the possible faker values within the generated recipe.

These record type driven faker values introduce a new "TODO" for the user as the user has to choose what set of Record Type value for the field and ensure any other record type associated TODO's are consistent with a chosen RecordTypeId.

This PR does introduce a "RecordTypeId" field if "recordTypes" directory exists but provides RecordType Developer Names. If using Workbench or postman to leverage the data set collection api files, until logic is introduced to query a target org before applying a data set, this RecordTypeId value will need the hardcoded record type ids of an expected org.

What does this PR do?

• Introduce logic to parse the "recordTypes" directory within an objects directory and generate a key-value map of record type to associated xml markup details
• updated unit tests to ensure scenarios where record types are included in the source directory, the generated recipes include the expected record type associated picklist options

---

Dependent Picklist Record Type options example:

---

Multiselect Picklist and standard Picklist Record Type options example:

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Other (please describe):

How Has This Been Tested?

• Tested on Windows
• Tested on macOS
• Tested on Linux
• Added new unit tests
• Updated existing tests

Test Details

[Describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration]

• Completed all commands with expected results
• added new unit tests for abstracted functionality
• updated unit tests for scenarios when there isn't any record type files and when there is record type files

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Additional Notes

[Add any other context, screenshots, or relevant information about the PR here]

Reviewers

@mention-team-members-or-specific-reviewers