## Summary

<!--
Ideally, there is an attached GitHub issue that will describe the "why".

If relevant, use this section to call out any additional information
you'd like to _highlight_ to the reviewer.
-->

_This is part of a
[series](#4813)
[of](#4848)
[PRs](#4849)
[being](#4851)
[spun](#4852) off from [my
WIP branch](lewisl9029#2) to get the
Highlight web app ready for [Reflame](https://reflame.app/). Hopefully
this makes things a bit easier to review, test, and merge. 🙂_

Previously we had a bunch of places where we imported
`/src/style/common.css` using the identifier `style/common.css`.
`style/*` was not setup as an alias in tsconfig.json, but this seem to
have worked anyways (I think it might be a quirk of the
https://github.com/aleclarson/vite-tsconfig-paths plugin).

I don't think it's a good idea to rely on this behavior over the long
term since there's nothing distinguishing it from npm package imports.

We could have worked around this by adding a `@styles` identifier like
we have for most other top level folders, but in this PR I proposed what
I believe is a more flexible option of simply exposing the src directory
as a `@/*` alias.

This has several benefits over manually setting up aliases for top level
folders separately:

- We can use it to import files on the top level as well (in my WIP PR I
added a env.ts module that didn't make a lot of sense anywhere else)
- Imports from `@/*` matches the filesystem directory structure exactly,
so there's never any ambiguity to where an imported file actually lives
on disk (in our current setup, we have 2 aliases that don't map 1:1 to
top level folders `@icons/*` and `@graph/*`)
- All else being equal, more path remapping rules will result in worse
performance for module resolution compared to fewer (though I haven't
ran the numbers to quantify this yet)

That said, this PR just introduces the new alias and uses it for
`@/style/common.css`, and doesn't change any other existing imports, so
none of these benefits are actually realized here. Though if the team is
interested in moving forward with this, I'd be happy to open up a follow
up PR to update imports throughout the rest of the codebase as well, and
try running a few benchmarks to see if it actually moves the needle on
performance.

Alternatively, let me know if y'all prefer to keep the current approach
using manual top level path remappings instead. I'd be happy to switch
over to a `@styles/*` import here as well.

## How did you test this change?

<!--
Frontend - Leave a screencast or a screenshot to visually describe the
changes.
-->

I ran the app using `yarn turbo run dev --filter frontend...`. 

## Are there any deployment considerations?

<!--
 Backend - Do we need to consider migrations or backfilling data?
-->

None that I'm aware of.

## Summary

<!--
Ideally, there is an attached GitHub issue that will describe the "why".

If relevant, use this section to call out any additional information
you'd like to _highlight_ to the reviewer.
-->

_This is part of a
[series](#4813)
[of](#4848)
[PRs](#4849)
[being](#4851)
[spun](#4852)
[off](#4907) from [my WIP
branch](lewisl9029#2) to get the
Highlight web app ready for [Reflame](https://reflame.app/). Hopefully
this makes things a bit easier to review, test, and merge. 🙂_

We had both a `CommentTextBody.module.css` and a
`CommontTextBody.module.scss` previously. The scss module seems to be
for regular component styling, while the css module seemed to be mostly
meant to contain classes for the `@highlight-run/react-mentions`
classNames prop integration.

I ended up renaming `CommentTextBody.module.css` to
`mentions.module.scss` to better reflect its purpose and distinguish it
from the main styling module, and so there wouldn't be any name
conflicts when generating corresponding .js modules for the Reflame
integration. There also seemed to be 2 classes in the css module that
didn't have anything to do with mentions, so I moved those out as well.

## How did you test this change?

<!--
Frontend - Leave a screencast or a screenshot to visually describe the
changes.
-->

Tested this out in the Reflame preview:

![Screenshot 2023-04-09 at 8 39 56
PM](https://user-images.githubusercontent.com/6934200/230821041-f2f54c8e-c351-48ca-b082-a0f1771dd625.png)

## Are there any deployment considerations?

<!--
 Backend - Do we need to consider migrations or backfilling data?
-->

We do probably want to verify in Render as well to make sure Vite has
the same exports output for CSS and SCSS modules.