require failures in bsconfig should produce a diagnostic and not crash the LSP process

Currently, when a require entry in bsconfig.json fails (e.g. missing module, syntax error in plugin), it throws an unhandled exception that takes down the entire LSP process. This is too destructive — a broken plugin in one project should not kill language intelligence for all open projects.

Proposed changes

• Wrap each require call in a try/catch
• Track the exact line/column position of the failing require entry in bsconfig.json so we can emit a proper diagnostic pointing to it
• Emit a logger.error(...) entry when a require fails
• Instead of crashing, signal to the LSP that this specific project failed to load (without bringing down the whole server)
• On initial startup: collect all project activation errors and send a single consolidated error message to the LSP client (rather than one popup per project — that's too noisy)
• On subsequent per-project reloads (e.g. bsconfig change): send an individual error for that project only

Why

One bad plugin or misconfigured require path should not break the LSP for all other projects in the workspace. Diagnostics should surface the problem precisely in bsconfig.json at the offending line.

Start by tracing how require entries from bsconfig.json are loaded during project activation and reloads, then inspect the LSP error-reporting path and logger.error usage. Done means failed requires produce a line/column diagnostic, log an error, preserve the server for other projects, consolidate startup errors, and report reload errors per project.