Add MLIR text model support via WebAssembly parser

[tucan9389]

Overview

This PR significantly enhances MLIR visualization by replacing the legacy, handwritten parser with tucan9389/mlir-js-parser. This migration establishes a robust, accurate, and extensible foundation for MLIR support in Netron.

Key Changes and Benefits

• Migration to the Official C++ MLIR Parser: We have replaced the previous implementation with the official C++ MLIR parser compiled to WebAssembly (Wasm). This ensures greater accuracy and ideal alignment with the MLIR specification.
• Improved Extensibility: By relying on the upstream C++ implementation, Netron can now more easily support new MLIR dialects and future evolutions of the standard.
• Reduced Maintenance Burden: While this PR vendors Wasm/JS artifacts, it removes approximately 1200+ lines of complex, handwritten parsing logic (significantly shrinking source/mlir.js), simplifying the maintainable codebase.
• Practical Coverage: The integrated parser provides meaningful, real-world coverage. As detailed in the StableHLO Coverage Report, it successfully parses 85% of 5449 StableHLO MLIR files.

Tooling and Deployment

• Dependency Management: A new script, tools/update-mlir-parser.js, has been introduced. This script automates the process of fetching the latest mlir-parser.js and mlir-parser.wasm artifacts from the upstream repository and updating the vendored copies in the third_party/ directory.
• ⚠️ Deployment Note: The required artifacts are checked into the repository. The deployment pipeline for netron.app must ensure these static assets (.js and .wasm files) are correctly included and served. Please also verify that the web server configuration serves .wasm files with the correct MIME type (application/wasm).

cc. @janpfeifer

[lutzroeder]

@tucan9389 thank you so much for digging into this. main now has a quick exploration what it would take to bring basic TableGen and dialects into JavaScript and see how far that approach can go. The WASM route looks promising too, so let's keep this open. How much can the .wasm size be trimmed and how would we handle dependency management and security if we went that way?