Reduce binary size by avoiding aggressive inlining of term decoding

[pguyot]

This leaves room for libs and programs

These changes are made under both the "Apache 2.0" and the "GNU Lesser General Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[bettio]

DECODE_COMPACT_TERM is used pretty everywhere, so avoiding aggressive inlining might reduce performances quite a lot, so let's review this from 2 different point of views:

• Module loading: not very frequent, we do this just once every time a new module is called. On ESP32 code size isn't a big constraint, but reducing size on a less frequent situation might be good anyway.
• Execution: here performance are critical so we need to find a way to make inlining level tunable. On targets such as ESP32 I would keep aggressive inlining.

We have following options on the table:

• macro
• (always) inline function
• regular function

Open points:

is the compiler able to peform same kind of optimizations on both the "macro" and the "(always) inline function" scenario?

If no, we might do this:

#define DECODE_COMPACT_TERM_IMPL(...)

#ifdef OPTIMIZE_SIZE

void decode_compact_term(...) { DECODE_COMPACT_TERM_IMPL }

#define DECODE_COMPACT_TERM(...)
decode_compact_term(...)

#else

#define DECODE_COMPACT_TERM(...)
DECODE_COMPACT_TERM_IMPL(...)

#endif

I'll investigate the real impact on the 2 scenarios for execution.