Add Support for Loading CSV datasets

[shenghann]

Description

PR stemming from this discussion: #1042
In summary, to add csv file loading functionality to anomalib on top of loading from folders for custom datasets.

The CSV dataset format:

    |---|-------|-----------|---------------|---------------------------------------|-------------|
    |   | split |  label*   | image_path*   | mask_path                             | label_index |
    |---|-------|-----------|---------------|---------------------------------------|-------------|
    | 0 |  test |  abnormal |  filename.png | ground_truth/defect/filename_mask.png | 1           |
    |---|-------|-----------|---------------|---------------------------------------|-------------|

• Single csv file containing following columns:
  • Required columns*:
    • image_path: Path to image file (to join with root from config.dataset.root)
    • label: normal, abnormal or normal_test
  • Optional columns:
    • split: If split column not defined in CSV, generate train and test splits the based on labels (same as how folder dataset handles this: normal samples = train, all abnormal and normal_test samples = test). Need to check that train split should only have normal. if abnormal found drop and ignore.
    • label_index: function of label where, normal = 0 and abnormal = 1
    • mask_path
• Defined in single new csv_file config key - path to csv file

Code changes:

• Add CSVDataset and CSV DataModule
• Add _prepare_filemeta_from_csv function in path.py using pandas to read CSV contents, ensure file required columns defined in csv file are correctly defined, have the correct extensions.
• Handling of required columns for DataModule _setup in make_csv_dataset
• Added support for test csv file during inferencing too - csv loading added in data/utils/image.py and lightning_inference.py

Also addresses #1072

Changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which refactors the code base)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist

• My code follows the pre-commit style and check guidelines of this project.
• I have performed a self-review of my 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 tests pass locally with my changes
• I have added a summary of my changes to the CHANGELOG (not for minor changes, docs and tests).

[samet-akcay]

Thanks for creating this PR. I've got few comments.

[djdameln]

Thanks, this is a nice feature to have. I have a few comments: