Add workarounds for postcss-values-parser error (negative values in calc())

[feral-grimalkin]

Description

There's an issue popping up every so often (e.g. #37079) where postcss-values-parser returns a syntax error when dealing with negative values in calc(). This PR is trying to fix this issue in Bootstrap 5.3.3.

Motivation & Context

This is to satisfy postcss-values-parser to allow successfully compile Bootstrap 5.3.3 in for example Rails 6 project or other projects using webpacker.

Type of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would change existing functionality)

Checklist

• I have read the contributing guidelines
• My code follows the code style of the project (using npm run lint)
• My change introduces changes to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

Related issues

I think at the moment there might not be an open issue for this. PR #37079 solved a very similar issue in the past, this PR uses the same approach to the recently introduced issue.

[feral-grimalkin]

Just to add some more context. This is not a bug in Bootstrap but in a css parser used in some pipelines. It was allegedly fixed in newer versions of the parser, but probably not backported, so it still affects some older projects. Updating the parser version might not be always possible given the spiderweb of dependencies.

Nevertheless as a very similar change was done in the past it'd make some sense to keep the code consistent, i.e. have calc(negative_value * #{$variable}) in all places. That said, it also doesn't feel very natural to now have calc(negative_value * #{$variable}) and calc(#{$variable} * positive_value) next to each other. 🤷

[louismaximepiton]

I think we missed it while changing some Sass variables but it seems logical to have this patch. Thanks for the patch!

[julien-deramond]

Thanks for the PR @feral-grimalkin

Globally, this syntax is more conventional so let's make this consistent in the entire codebase. I haven't spotted any issues with manual testing. I'm always careful with @if $pagination-margin-start == calc(-1 * #{$pagination-border-width}) as the order is important in the comparison, but it seems to work well.

In the generated bootstrap.css, the diff seems safe as well:

2782c2782
<   margin-left: calc(var(--bs-border-width) * -1);
---
>   margin-left: calc(-1 * var(--bs-border-width));
3755c3755
<   margin-left: calc(var(--bs-border-width) * -1);
---
>   margin-left: calc(-1 * var(--bs-border-width));
3802c3802
<   margin-top: calc(var(--bs-border-width) * -1);
---
>   margin-top: calc(-1 * var(--bs-border-width));
4803c4803
<   margin-left: calc(var(--bs-border-width) * -1);
---
>   margin-left: calc(-1 * var(--bs-border-width));

I'll add @louismaximepiton as a co-author as the same fix was suggested in #39108