Extend invalid escape sequences rule to other tagged template literals

[mikejamesthompson]

Template literals used as values for the css and svg tag functions are vulnerable to the same issues with invalid escape sequences as the html tag function.

For example the following code leads to an empty CSS result with no error or warning to indicate what's gone wrong:

const styles = css`
  p::before {
    content: "\2716";
  }
`;

I'd be in favour of expanding the no-invalid-escape-sequences rule to cover these other kinds of template literals.

Happy to do a PR for this with docs changes if that's helpful.

[43081j]

i think you're right

so far we've stayed away from the css templates since something like stylelint should be responsible for that. but this particular case is actually about the JS around the template, so we're probably ok.

we should probably create some util function like isLitTemplate which basically asserts that its a html, css or svg tagged template expr.

we don't need to update the other rules to use that yet, so we can keep this tightly scoped. then just need to update the docs to mention that we check all 3 for this rule