Fix windows compatibility regression of task dir key

[per1234]

The dir key can be used to specify an arbitrary working directory for the task.

This is used in npm-related tasks in order to provide support for projects that contain an npm project in a subfolder. Taskfile variables are used for this purpose.

The template syntax used in Taskfiles is a bit problematic for use in YAML due to the fact that the template's brace-wrapped format is also used by YAML's alternative "flow style" mapping syntax. This means it is necessary to use syntax that explicitly defines values that consist only of a template as having a string type. That can be accomplished through the use of quotes, but since the use of quotes is typically not required in YAML, they are generally eschewed, and are instead only used in the shell code embedded in the tasks. For this reason, the alternative syntax of a "block scalar" was chosen.

That approach worked at the time the system was established, and continues to work on POSIX machines. However, it seems there was a change in the handling of the dir key on Windows in recent versions of Task. This causes the tasks that used this approach to now fail spuriously:

task: Failed to run task "npm:install-deps": could not stat: CreateFile E:\arduino-lint\"\"
: The filename, directory name, or volume label syntax is incorrect.

There are actually two separate problems:

The first is the unnecessary wrapping of the value in quotes. Although wrapping paths in quotes is best practices in shell code (in order to support paths that contain characters that would be problematic if unquoted, e.g., spaces), it is not necessary in the dir key, which is not shell code and will correctly handle the unquoted path. On Windows, the quotes are being interpreted as literal characters in the path rather than syntax.

The second is that the basic "literal block scalar" syntax (|) results in there being a newline at the end of the value. This is also being interpreted as a literal character in the path.

The obvious solution to the first problem is the removal of the quotes, which were always superfluous. One solution to the second problem would be to add the "block chomping indicator" (|-). However, since the the "block chomping indicator" syntax is relatively obscure and not used elsewhere in the assets, it seems that the balance now shifts to the basic "flow scalar" syntax being more clear and maintainable than the "block scalar" syntax.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.33%. Comparing base (786f70b) to head (debe8cc).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #950   +/-   ##
=======================================
  Coverage   83.33%   83.33%           
=======================================
  Files           1        1           
  Lines         180      180           
=======================================
  Hits          150      150           
  Misses         19       19           
  Partials       11       11           

Flag	Coverage Δ
unit	83.33% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.