Draft: Handling view errors more cleanly (and factorizing some code to reuse code from entrypoint errors)

Motivation and Context

To ensure that users migrating to v1 got decent error messages, a quick and dirty handling of view errors was added in !2901 (merged). The goal of this MR is to remove it and to have view errors handled in the same way that entrypoint errors are.

Description

TODO

Component

• compiler
• website
• webide
• vscode-plugin
• debugger

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Performance improvement (non-breaking change that improves performance)
• None (change with no changelog)

Changelog

Checklist:

• If a new syntax has been introduced, put a message on slack ligo-lsp
• Changes follow the existing coding style (use dune @fmt to check).
• Tests for the changes have been added (for bug fixes / feature).
• Documentation has been updated.
• Changelog description has been added (if appropriate).
• Start titles under ## Changelog section with #### (if appropriate).
• There is no image or uploaded file in changelog
• Examples in changed behaviour have been added to the changelog (for breaking change / feature).