Inline AddNode specialization that are not yet inlined into InlinedAddNode

[smarr]

This change improves interpreter speed on microbenchmarks like Mandelbrot, Sieve, Storage, reducing run time by 7%.
More interesting benchmarks, don't really show any change.

Performance report here: https://rebench.stefan-marr.de/compare/TruffleRuby/069b9e68efef1a09f6fa2a2c722059af43e300ae/60c3282176185aa99c0f1ab8c727c6e6822c8513#ruby-startup-TruffleRuby-native-interp

The drawback is that this duplicates logic from the AddNode. Though, the logic duplicated seems trivial, and the double logic was already duplicated to start with.

[eregon]

This looks good, thanks, I'll also do it for InlinedSubNode for consistency.

In general Inlined*Node do inline the logic if it's trivial (hence it was done for double), here it's not fully trivial but still reasonably simple and short (two 1-line specializations). I'll probably cross-link them via JavaDoc to keep them in sync (e.g., the addWithOverflow(long, long) could probably do something better by doing a fast-path overflow check in the future).

[eregon]

There is one bug here that each of these specializations should check the Assumptions with assumptions = "assumptions".

[smarr]

Hm, so, not sure whether this is a huge win overall.
https://rebench.stefan-marr.de/compare/TruffleRuby/069b9e68efef1a09f6fa2a2c722059af43e300ae/fd203cf9f8a1f3351ee64c863d42d8b9ff441050#ruby-startup-TruffleRuby-native-interp

Results are generally indicating a reduction of interpreter run time, but it's small I'd think.

[eregon]

Maybe the Assumption[] checks are not so cheap (1 volatile read per Assumption + iterating the array).
I think it might be possible to reduce it to checking a single Assumption (right now it's 3, 2 for Integer#+ and Float#+, and 1 for set_trace_func).
For set_trace_func it might be possible to rely on instrumentation to replace with a full call node as needed with materializeInstrumentableNodes().