Provide actual messages in JS errors

[sagudev]

Now that each error variant accepts Option<String> (#39053), we should start to write actually error messages instead of passing None.

OFF-TOPIC: Should we accept Cow rather than string? Or maybe even create JSString directly? (probably not).

[jschwe]

I kind of forgot about this topic, but to pick up from the old one:

Would it make sense to use thiserror?

I think not, as the errors are converted to JS exceptions not used by rust code and each error needs new message, so we would need giant enum of possible msgs.

Im still wondering if we could use thiserror / anyhow / some other error library. My goal / usecase would be to be able to control the conversion to JS exception formatting, so that we don't need to bloat the binary size with tons of error strings, but could have a "min-size" option, where we use an approach like defmt does, of moving the error message formatting to some offline step. If we had an error library, the default option would be to convert the error into a string, but this would give us the flexibility to do deferred formatting if needed. I don't think we would need one big error enum either, we could use [#from], or perhaps just use a dyn Error trait?

[jdm]

An easy place to start with adding meaningful error messages is in WebCrypto code like https://github.com/servo/servo/blob/main/components/script/dom/subtlecrypto/aes_operation.rs . Code like https://github.com/servo/servo/blob/2982929210ae694dbb775d937c5dec0a9b0fea33/components/script/dom/subtlecrypto/aes_operation.rs#L56-L64 could be split into two different conditionals that return more specific error messages like "Algorithm counter length is not 16".