Add "listing" flag support to theme commands

[chrisberthe]

Follow up to #6002.

WHY are these changes introduced?

Shopify introduced new requirements for the Shopify Theme Store that require themes with multiple presets to include a /listings directory in their theme zip submissions. However, developers need a way to preview and test these specific theme presets during development and deployment.

WHAT is this pull request doing?

• Added --listing flag to shopify theme dev, shopify theme push, and shopify theme share commands
• Implemented "file overlay" to serve listing-specific templates and sections when available
• Updated theme file watching to monitor the active listing directories during development
• Added config/settings_data.json preset switching, i.e. "current" key, based on listing name

How to test your changes?

1. Create a theme with a listings/ directory:

   theme/
   ├── listings/
   │   ├── preset-name-one/
   │   │   ├── templates/
   │   │   │   └── *.json
   │   │   └── sections/ (optional)
   │   │       └── *.json
   │   └── another-preset-name/
   │       ├── templates/
   │       │   └── *.json
   │       └── sections/ (optional)
   │           └── *.json
   

2. Test development with listing:

   shopify theme dev --listing preset-name-one

3. Test push with listing:

   shopify theme push --listing another-preset-name

4. Test share with listing:

   shopify theme share --listing preset-name-one

5. Verify that listing-specific files are served when they exist, and base theme files are used as fallbacks when they don't

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
• Existing analytics will cater for this addition
• PR includes analytics changes to measure impact

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[graygilmore]

Testing this out with theme dev worked well! Very neat! Couple of pieces of feedback and I'll ping the rest of the team to get one more set of eyes because I'm not too familiar with some of the pieces in here.

[graygilmore]

🧵 I'm not seeing any validation around if a user provides a --listing value that doesn't exist. I think we should stop the command and return an error otherwise they'd be left assuming their command worked but we actually never found a matching listing.

[chrisberthe]

Fair point. I originally had a number of validation checks for this and ultimately decided on removing as I wasn't sure where to draw the line with what the CLI validates for versus the platform.

Currently, if you specify a non-existent listing, the platform will output an error about this, i.e. settings_data.json error when the "current" key is set to a non-existent preset/listing, but this will only happen after the dev server boots up, not before, which perhaps is less ideal than throwing an error before files are synced.