feat(pv-scripts): replace using node-sass with (dart-)sass

[mbehzad]

Switch do dart-sass instead of node-sass for processing .scss files

Dart Sass is currently the active implementation of sass and gets new features. It is stable for a long time now, and imo it makes sense to switch to it.

Pros

• allows usage of modern CSS syntax. For example width: min(100px, 10vw); instead of weird workaround via interpolations: #{"width: min(100px, 10vw);"}
• Better modularization possibilities
• node-sass binaries are tied to the node version which means changing node version is coupled to the need of re-downloading node-sass binaries. etc.

Cons

• not being able to use / for division. e.g.

// node-sass
width: 100% / 3;


// dart-sass
@use "sass:math" as *;

width: div(100%, 3);

// or use the browser to do the job:
width: calc(100% / 3);

There is a sass-migrator cli tool which can help automatically update the codebase.

• it compiles noticeably slower (e.g. on a ~50 components repo it took 1.5 -2 times to compile the scss compared to the current node-sass)
  But once sass-loader can use the native Dart Sass executable, this would be less relevant (see Option to use the DartVM executable rather than the pure-js version of dart-sass. webpack-contrib/sass-loader#774).

Breaking?

Technically it would probably compile successfully our code bases so it isn't a breaking change. But that will generate a lot of deprecation warnings regarding the usage of slash for division.
see https://sass-lang.com/documentation/breaking-changes for possible breaking changes

User preference

It is also possible to allow the user to choose between these two sass implementation by:

1- property in pv.config.js
2- sass not being a direct dependency of pv-script, and the user has to install node-sass or sass themselves. (similar to CRA which we have its error message already in formatWebpackMessages.js#L79

== Closes issue(s) ==

== Changes ==

== Affected Packages ==
pv-scripts