feat: Add compile-time type validation for column specifications and optimize performance

[brndnblck]

Summary

• Implements runtime type validation during schema building to catch type mismatches that can't be detected at macro expansion time (e.g., type alias shadowing)
• Adds full bool primitive support across all drivers (SQLite, PostgreSQL, MySQL)

Key Features

• Schema-time validation in toasty-core/schema/verify.rs - catches issues at runtime during schema building
• Whitelist approach for maintainability (explicit compatible types)
• Type alias detection - handles complex scenarios that macros cannot (like type String = u32)
• Clear error messages with type suggestions for better developer experience
• Full bool primitive support including SQLite INTEGER(0/1) value conversion
• Comprehensive test coverage - both runtime validation and integration tests

Changes Made

Core Implementation

• crates/toasty-core/src/schema/verify.rs - Added verify_column_type_compatibility() with helper methods
• crates/toasty-core/src/stmt/value.rs - Bool value conversion support
• crates/toasty-driver-sqlite/src/lib.rs - SQLite bool storage as INTEGER (0/1)

Test Coverage

• tests/tests/field_column_type_validation.rs - Valid type combinations
• tests/tests/schema_validation_test.rs - Runtime validation error cases
• tests/tests/tys.rs - Bool primitive integration tests

Problem Solved

Original issue (#185): Type validation at macro time fails with type aliases

Example that was problematic:

type String = u32;  // shadows built-in String

#[derive(toasty::Model)]
struct User {
    #[column(type = text)]
    name: String,  // This is actually u32, not String!
}

Macro-time validation can't detect this because it sees the identifier String and assumes it's std::String.

Schema-time validation (our solution) catches this at runtime during schema building when the actual stmt::Type is resolved.

Architecture Decision

Following maintainer feedback (@carllerche), we moved validation from macro expansion time to schema building time:

• Macro-time: Can't handle type aliases reliably
• Schema-time: Validates actual resolved types at runtime

Benefits

• Catches type mismatches at schema build time (not database runtime)
• Handles complex type alias scenarios that macros cannot
• Provides clear error messages with type suggestions
• Maintains type safety without runtime overhead during queries
• Extensible design - easy to add new type compatibility rules

Fixes #185

[carllerche]

Thanks for the PR. Direction wise, I don't think we can reliability do the check in the macro. For example, above the macro, there could be type String = u32;. So, the only safe way to do the check is when building the toasty schema struct. Maybe something in here? https://github.com/tokio-rs/toasty/blob/main/crates/toasty-core/src/schema/verify.rs

[brndnblck]

Thank you for the feedback @carllerche. I was coming to a similar conclusion late last night as I was trying to iterate on this, but ran out of time and steam. I'll move this back to draft for now so it doesn't clutter the list of PRs, but should be able to revisit this in the next couple of days.