ENH: Add Fill Functionality to Create Array Action & Utility File Refactoring

[nyoungbq]

Fixes: #1274

Added Functionality:

• Create Array Action now accepts a string that will be transformed into a fill value
• Smaller executable size
• Smaller utility files
• Smaller headers nearly project wide
• DataArrayUtilities segmented into applicable utility files
• Easier debugging by removing various common macros (now templates)
• Simplified string to number conversions
• Integrated sanity check for intialization string in CreateArray for both preflight and execute
• Backported new fill functionality

Changes:

• Moved MaskCompare functionality from DataArrayUtilities to MaskCompareUtilities
• Moved Convert (string conversion) functionality from DataArrayUtilities to StringInterpretationUtilities
• Moved CreateArray functionality from DataArrayUtilities to ArrayCreationUtilities (therein removing the biggest utility file from being included in most Action headers)
• Moved CreateDataStore functionality from DataArrayUtilities to DataStoreUtilities (therein removing the biggest utility file from being included deep in the datastructure factory functions that are included in nearly everything by proxy)
• Reworked dependencies for aformentioned utility files to make them standalone (except ArrayCreationUtilities which includes StringInterpretationUtilities and DataStoreUtilities)
• Added a method to DataStore for setting initialization value (this was done to meet the request of issue (ENH: Create arrays in preflight with a default initialization value. #1274)). The request was originally to pass it to the ctor (This would require reworking AbstractDataStore, and every factory function and mapping for all of OoC functionality, hard to over emphasize how much of a downstream effect this would have) DataStore is the only one that has an initialization value.
• Scoped all moved functionality to respective namespaces
• Removed Macros for string to number convert functions (created simplifed templates instead)
• Removed ArrayFromPath functionality (this cut an extra unnecessary dynamic cast) and made code conform to modern access patterns. This also removed the need to include DataArrayUtilities in various headers.
• Removed various extraneous string to number convert functions in favor of new simple, unified convert call system
• Lots of include cleanup to help cut down executable size and downstream header bloat

Naming Conventions

Naming of variables should descriptive where needed. Loop Control Variables can use i if warranted. Most of these conventions are enforced through the clang-tidy and clang-format configuration files. See the file simplnx/docs/Code_Style_Guide.md for a more in depth explanation.

Filter Checklist

The help file simplnx/docs/Porting_Filters.md has documentation to help you port or write new filters. At the top is a nice checklist of items that should be noted when porting a filter.

Unit Testing

The idea of unit testing is to test the filter for proper execution and error handling. How many variations on a unit test each filter needs is entirely dependent on what the filter is doing. Generally, the variations can fall into a few categories:

• 1 Unit test to test output from the filter against known exemplar set of data
• 1 Unit test to test invalid input code paths that are specific to a filter. Don't test that a DataPath does not exist since that test is already performed as part of the SelectDataArrayAction.

Code Cleanup

• No commented out code (rare exceptions to this is allowed..)
• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added example pipelines that use the filter
• Classes and methods are properly documented