Feat/ODBC Browser, History Table ODBC, New Parameter Table

[MatthewReed303]

ODBC Browser and Enhanced Table Features

This PR introduces comprehensive ODBC database integration and enhanced table functionality to FUXA SCADA.

Key Features Added:

ODBC Browser

• New ODBC browser component for database exploration and query building
• Support for browsing database schemas, tables, and columns
• Query builder service with SQL syntax assistance
• Column definition analysis (types, constraints, relationships)

Database Integration

• ODBC driver handling and database connection support
• Date formatting utilities for ODBC queries
• Enhanced DB support with proper data type handling

New Parameter Table Type

• Complete parameter table implementation with full backend support
• CRUD operations for parameter management
• SQLite and ODBC datasource integration
• Auto-write functionality on application startup

Table Enhancements

• Improved history table with chunked data loading for large datasets
• Hash-based data integrity checks
• Enhanced UI with better styling and user experience
• Optimized large data handling and auto-refresh capabilities

Technical Changes:

• Added ODBC device runtime support for different database types
• New API endpoints for parameter table management
• Enhanced table components with advanced features
• Improved data persistence and caching mechanisms

[concept10]

500,000 LOC on this PR. Wow (ridiculous IMO no matter the added functionality) but that's just me.

[unocelli]

Nice work on this feature — it’s a pretty big addition 👍

As a first pass, I’d fix a couple of high-level things before we go deeper:

1. Build artifacts

Please remove the generated build files from the PR.

2. Security (ODBC / DB access)

Since this introduces quite a bit of database and ODBC logic, we should double-check the security side — especially how queries are handled on the server.

Where possible, we should prefer parameterized queries instead of building SQL strings dynamically. For example:

const query = `SELECT * FROM users WHERE id = ${userId}`;

would be safer as:

const query = `SELECT * FROM users WHERE id = ?`;
const result = await connection.query(query, [userId]);

This way the driver handles escaping and we reduce injection risks.
For dynamic identifiers (like table names), we should make sure they are resolved server-side from a controlled source rather than trusting raw client input.

3. ODBC device access

The API lets the client choose the storage type and ODBC device. We should make sure this follows the same authorization pattern used in similar endpoints — i.e. enforce the check when authorization is configured, just like we do elsewhere.

Once this is clarified/adjusted, we can go through the implementation in more detail.