RECEIVE iCode op inconsistently printed without indent, fix that.
Refactor printiCChain() to use piCode(), avoid duplicate code.
Support for outputting flat iCode.

Add --emit-i-code switch to dump (to *.dumpicode file) iCode immediately
after its creation, and before splitting into basic blocks, etc.
Add support for rendering "external representation" of iCode.

External representation contains information more pertinent to the
iCode itself and less to how it was created, in particular, there's
no source line-numbering data, etc. The idea behind external representation
is to allow read it back into SDCC. Then, it will be possible to generate
iCode from other compiler frontends and codegenerate fot 8-bit MCUs via
SDCC.

This commit also changes rendering mode for operand flags - instead
of using long strings with items like "as:0", only flags with non-zero
values are rendered, which produces more readable and easier to
understand. Note that this change also applies to original "debugging
representation" of iCode.
SDCCmem: Allow to associate short human-readbale names with address spaces.

Given an address space map, its name can be found via ->name, and a map
can be found by name using getMapByName(). Address maps used to contain
->sname member, but it has nothing to do with human-readability or
consistency - it's value varies port by port, and usually represents
string like "SEG   (DATA)".

The implementation somehow duplicates "named address spaces" implementation,
which actually named pretty confusingly - what it implements not "named
address spaces" per se, but *custom* named spaces for variable bank switching
support.
Dump address spaces used by iCode operands.
Dump function types as they are, without adhoc tricks.

SDCC dumps all types as they are, and only function types suddenly
dumped with adhoc "function" sticking into. This will break parsing
of such type (essentially, it's not a type, but a declaration).
Hopefully, folks who look into compiler representation know that
there's function type in C, it's written like "int()" (function),
and the fact that it's promoted to a pointer to a function "int (*)()"
is separate issue.