Add type and dimensions in command line output of expressions

The proposed mechanism aims to display an "outline" of object, i.e. its type and dimensions (if applicable), e.g.

--> uint8(x*256)

 ans = [5x5 uint8]

  145   31  189  160    6
  146  186    0   29  132
  208   68  151  156  100
   14  139   79  173   61
  143  253   65   84  129

--> num2cell(x)

 ans = [5x5 cell]

  0.5667211    0.124934     0.7395657    0.6251879    0.025871 
  0.5711639    0.7279222    0.0037173    0.1157417    0.5174468
  0.816011     0.2677766    0.5900573    0.6117004    0.3916873
  0.0568928    0.5465335    0.3096467    0.6783956    0.2413538
  0.5595937    0.9885408    0.2552206    0.3320095    0.5064435

The implementation determines this "outline" by using the overloading mechanism, e.g. the two above outputs are using %i_outline(x,verb) and %ce_outline(x,verb). The second argument verb allows to eventually control the verbosity of this outline. In the internal ast display of expressions the outline overload is always called with verb=1 but when called from a context where this outline should be more compact, e.g. when displaying an object within a container, it can be called with verb=0.

In fact, this outline was already used in containers display (lists, mlists, tlists, structs, cells) and in other non container types with overloaded extraction, i.e. XMLObjects, External Java objects and classes, Xcos objects, but with several different implementations and with different rendering. One way of unifying this rendering was to use the same outline overloads in the multi-purpose macro %l_string_inc() (which has been rewritten from scratch). Since calling adequate overloads in Scilab functions is less straightforward than calling them from the ast module, the code of %l_string_inc() cannot be fully optimized and factorized.

In order to unify further this "container objects display", a common mechanism of getting the allowed field names considered in extraction and in containers display is proposed by allowing overloads of fieldnames(), which has already been specialized for some types in its C++ gateway. The rationale for this proposal is that, for numerous objects types, what is actually yielded by fieldnames(x) differs from the field names e allowed in extraction and insertion x(e) (see for example XMLObjects) and that can be displayed (exhaustively or not). The output of fieldnames for a given object could also feed the completion dictionary (see the old !700).

After this patch, the display of Scilab objects is unified, improved and easy to maintain.