[no_std] Consider replacing panic!() with thiserror for more flexible error handling

[dengyt2018]

Hi! I've been using crc-fast in a no_std environment and noticed that some error cases use panic!() which can be problematic for embedded systems where we need to handle errors gracefully rather than having the program abort. It would be really helpful if the library could switch to using the thiserror crate to return proper error types instead, giving users the flexibility to decide how to handle errors in their specific contexts. This would make the library much more suitable for no_std and embedded use cases while maintaining its excellent performance characteristics. Thanks for considering this suggestion!

[onethumb]

@loadingalias Thoughts? ☝️

[loadingalias]

@dengyt2018 is right. At the time, I didn't want to presume that you wanted thiserror in the codebase. It should absolutely be used and thiserror v2 support for no_std is pretty solid; I've already done this in my private 'playground' fork of crc-fast-rust. I just wasn't sure what direction you planned to move in.

I think the addition is a great one and one that can be used across the codebase. Ultimately, this is your show. Want me to take a look? It shouldn't be that heavy of a lift - I've got most of it done in my own local fork anyway.