Resolves #1378

This implements a parser for SPDX license expressions in accordance with
[annex D of the v2
spec](https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/),
to allow the scanner to properly determine if packages with such
expressive licenses are permitted based on the licenses allowed by the
user.

To do this I've implemented a two-phase parser which starts by
tokenizing the license string and then turns it into an AST of nodes
that can be walked to determine if the full expression is satisfied; for
no particularly good reason I have used a string for the base token type
rather than a `struct`, meaning the tokens value is also it's type - the
tradeoff with this is while it means we don't have to do as much
referencing or work in the tokenizer, we do have to do some extra work
when walking the tree to resolve the "simple expression" tokens.

I'm proposing landing the current implementation as I don't think using
a `struct` would be strictly better, though in hindsight it probably
would have been a bit quicker to implement and so I plan to explore how
much simpler (or complex) it might be as a follow up.

Currently this is focused on `AND` and `OR` support, as I believe those
are the two primary operators that are relevant to the scanner, though
we still might want to have richer handling for the `WITH` and `+`
operators; currently both of those just get treated as being part of the
license expression (though it's not actually possible right now to allow
a license with `WITH` as the CLI expects license values to not have any
spaces - this too will be a follow-up for me).

Finally, I've purposely not put any caching in place even though that
should be easy, due to wanting to get this landed and as I don't expect
it to actually have a significant impact on the scanner performance
(ultimately most complex expressions in the real-world will be made up
of a single operator, and chopping+looping over strings in memory is
extremely fast)

Resolves #1299

#1329 removed the slices import in `vulnerability_result.go`, because it
was no longer using it.
At the same time, #1385 added a new usage of the module.

Add the import back to make osv-scanner build again.

HTML output added #1258

New design (sample one: https://hogo6002.github.io/scanner-report/):
- Changed the color scheme to match osv.dev.
- Merged the package view and vulnerability view into a single nested
table.
- Added a layer view.
- Added a vulnerability type filter (project, OS, and uncalled).
- Added a vulnerability search bar.
- Refined the vulnerability severity count design.
- Integrated the osv.dev vulnerability page into results (allowing users
to click to view details).
- Improved the UI.

Future plan:
Use frontend framework to enhance code maintainability and readability


![image](https://github.com/user-attachments/assets/5aa1559d-3d41-4ce1-9aff-6e68c25200ac)

![image](https://github.com/user-attachments/assets/e23d7a97-b295-4d10-a8cc-1350dd33576e)

![image](https://github.com/user-attachments/assets/849dc0cf-2b12-4bc9-a08a-10b426d16155)

![image](https://github.com/user-attachments/assets/ba787cda-3e07-479a-976d-171de4db6c7e)

---------

Signed-off-by: Holly Gong <gongh@google.com>

…1398)

Corrected JSON field names in the osv-scanner documentation. Previously,
one key was incorrectly called `sourcePackage` and was changed to
`source`.

Closes #1391

Co-authored-by: Holly Gong <39108850+hogo6002@users.noreply.github.com>