[Indented syntax improvements] Dart implementation

[jamesnw]

Blocked until proposal is accepted.

• sass-spec [Indented syntax improvements] Specs sass-spec#2041

[skip sass-embedded]

[jamesnw]

@nex3 This is ready for review. Here are some questions I wanted to flag as you review. Thanks!

1. allowNewlines is set to true in some cases, like in parser* functions or in scss.dart, where the value is non-impactful. Should this usage be differentiated somehow for clarity?
2. There are some places, like in _atRootQuery, where allowNewlines is true because it is inside parentheses. I opted to not use the _inParentheses variable except for one place where the consumption did rely on it, in _supportsCondition. Would it be more idiomatic to use _inParentheses, even if the consumption is in the same function?
3. In the + include syntax, I am not supporting whitespace after the + as it can be part of a selector. This differs from the = mixin syntax- should they be the same?
4. I added paren/bracket context to almostAnyValue, with the only change being that they must be matched. That means the error for a:has(d[)] will be changed from "Expected identifer" to "Expected ]". Since almostAnyValue is used for more than selectors, should I make this functionality opt-in, dependent on a parameter? Based on the places where this is used, I don't foresee issues with bracket matching, but want to verify.