Add relevant features/snapshot properties bitset to snapshot header

[martijnthe]

I noticed that certain features affect the snapshot output format (logically so):

• whether uncompressed / 32-bit pointers is enabled
• machine endianness
• js-parser-limits.h values – PARSER_MAXIMUM_CODE_SIZE affects the byte code generation. I'm not sure if any of the other parser limit values are relevant when loading a snapshot.
• whether RegExp literal templates are used in the snapshot (a JerryScript VM that is compiled w/o RegExp support will hit JERRY_UNREACHABLE () when loading a snapshot with a regular expression template literal)
• probably more...?

Right now, there's no nice way to check whether a snapshot is really compatible before running it.
Would it make sense to add this information to the jerry_snapshot_header_t?

@LaszloLango also hinted on IRC at that the magic strings list may also cause snapshots to become different, but I did not observe this when comparing outputs.

[LaszloLango]

I think storing such information in the snapshot header is a good idea.

[jiangzidong]

+1
And about the magic string, our magic strings are different (e.g. I changed the lit-magic-strings.inc.h), then your snapshot may not run in my jerry, because the magic string idx may indicate different strings.

[jiangzidong]

About the whether uncompressed / 32-bit pointers is enabled will affect the snapshot output, is that ONLY resulted from the padding in cbc_uint16_arguments_t? But I dont know why we need the padding?

typedef struct
{
  ecma_compiled_code_t header;      /**< compiled code header */
  uint16_t stack_limit;             /**< maximum number of values stored on the stack */
  uint16_t argument_end;            /**< number of arguments expected by the function */
  uint16_t register_end;            /**< end position of the register group */
  uint16_t ident_end;               /**< end position of the identifier group */
  uint16_t const_literal_end;       /**< end position of the const literal group */
  uint16_t literal_end;             /**< end position of the literal group */
#ifdef JERRY_CPOINTER_32_BIT
  uint16_t padding;                 /**< an unused value */
#endif
} cbc_uint16_arguments_t;

[martijnthe]

I updated the list in the description with the things that affect the snapshot output.

@zherczeg: you are much more familiar with this. Could you comment? Thanks.

[jiangzidong]

@zherczeg Do you know why do we need the padding in

typedef struct
{
  ecma_compiled_code_t header;      /**< compiled code header */
  uint16_t stack_limit;             /**< maximum number of values stored on the stack */
  uint16_t argument_end;            /**< number of arguments expected by the function */
  uint16_t register_end;            /**< end position of the register group */
  uint16_t ident_end;               /**< end position of the identifier group */
  uint16_t const_literal_end;       /**< end position of the const literal group */
  uint16_t literal_end;             /**< end position of the literal group */
#ifdef JERRY_CPOINTER_32_BIT
  uint16_t padding;                 /**< an unused value */
#endif
} cbc_uint16_arguments_t;

[LaszloLango]

@jiangzidong @martijnthe The padding was introduced by this PR #1764
AFAIK the issue was reported by the address sanitizer of GCC.

cc: @bzsolt

[akosthekiss]

With #1797 being landed, can we close this issue? Or are there any known bits still requiring follow-up work?