Add no-assert-string feature

[wcampbell0x2a]

When no-assert-string is enabled, remove string generation in .rodata section. When writing parsers made for embedded platforms that are limited in storage these strings add up when many assertions are added.

[github-actions[bot]]

Benchmark for e51d275

Click to view benchmark

| Test | Base | PR | % | |------|--------------|------------------|---| | deku_read_bits | **1099.2±17.01ns** | 1144.4±14.90ns | **+4.11%** | | deku_read_byte | 23.2±0.43ns | **22.7±0.39ns** | **-2.16%** | | deku_read_enum | 9.4±0.16ns | 9.3±0.12ns | -1.06% | | deku_read_vec | 53.3±0.83ns | 53.3±0.72ns | 0.00% | | deku_write_bits | 113.0±1.29ns | **108.7±3.40ns** | **-3.81%** | | deku_write_byte | 140.3±6.10ns | **122.7±2.41ns** | **-12.54%** | | deku_write_enum | 92.7±6.25ns | **86.1±4.66ns** | **-7.12%** | | deku_write_vec | 3.1±0.03µs | 3.1±0.03µs | 0.00% |

[github-actions[bot]]

Benchmark for 7c221b9

Click to view benchmark

| Test | Base | PR | % | |------|--------------|------------------|---| | deku_read_bits | 1124.9±13.34ns | **1109.6±18.58ns** | **-1.36%** | | deku_read_byte | 23.4±0.97ns | **22.5±0.42ns** | **-3.85%** | | deku_read_enum | 9.5±0.10ns | 9.5±0.07ns | 0.00% | | deku_read_vec | 53.8±0.46ns | 54.2±0.87ns | +0.74% | | deku_write_bits | 113.1±1.87ns | 111.8±8.35ns | -1.15% | | deku_write_byte | 124.1±4.25ns | 125.7±7.15ns | +1.29% | | deku_write_enum | 86.0±4.27ns | 87.0±4.84ns | +1.16% | | deku_write_vec | 3.2±0.04µs | **3.0±0.03µs** | **-6.25%** |

[sempervictus]

Wonder if some sort of rainbow table/heuristic dictionary or compression based approach would help provide middle ground for more usable string space with qualified lookup/decompression speed. Some sort of checksum dictionary stored in runtime might also be more efficient since its not really the bytes of the strings we're usually asserting but their equivalence to X or Y which matches pre-computed hashes.

[wcampbell0x2a]

Wonder if some sort of rainbow table/heuristic dictionary or compression based approach would help provide middle ground for more usable string space with qualified lookup/decompression speed. Some sort of checksum dictionary stored in runtime might also be more efficient since its not really the bytes of the strings we're usually asserting but their equivalence to X or Y which matches pre-computed hashes.

Interesting idea, it could return a hash of both the struct/enum and field which could be reversed at runtime if you wanted that information. That would take some design, this is easier for me to just turn on and not have extra bytes of data..