Remove a loop counter, that isn't actually used for anything.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

Currently LLEXT has two ways to export symbols:
EXPORT_SYMBOL() to exort symbols from the main firmware to extensions
LL_EXTENSION_SYMBOL() to export symbols from extensions
but it is possible to write code, that needs to export symbols
regardless of whether it is built into the main image or an
extension. And in fact there's no real need in two distinct macros -
we can use one for both cases and recognise at build time which
direction exporting is happening. This patch extends EXPORT_SYMBOL()
to also work from extensions.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

Replace LL_EXTENSION_SYMBOL() with EXPORT_SYMBOL() in all tests and
samples.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

LLEXT objects can also export symbols for use by other such objects.
That means, that when linking an LLEXT object we have to look for
unresolved symbols in previously loaded objects too.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

Using the immediate logging option from LLEXT modules requires
one more symbol export.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

When deciding which sections to group together, only the low 3
section attribute bits are relevant, ignore the rest.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

When an LLEXT object uses symbols of another such object, it depends
on it. Such dependencies have to be tracked to prevent their
accidental unloading. Ideally we should be able to track arbitrary
numbers of such dependencies, but this is a bit difficult. In this
first implementation we use a fixed-size array, currently consisting
of 8 entries.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>