* zhird/leoliu/dbg_wx_trace/arg-to-gui_enable_updown:
  Fix argument to gui_enable_updown in dbg_wx_trace:init/6

Fix comment on new_process message in int:subscribe/0

Applications that use the new erl_anno module are depending on STDLIB 2.5.

Note that CosNotification, Megaco, SNMP, Xmerl, and Parsetools use the
erl_anno module via the Yecc parsers only (the header file in
lib/parsetools/include/yeccpre.hrl calls the erl_anno module).

HiPE does not call the erl_anno module, but uses an exported type.
We have chosen to make HiPE dependent on the erl_anno module.

Make sure that we recognize map literals at load time, as we
do for lists and tuples. Also use maps:from_list/1 to build
a new map instead of building it up from scratch inserting one
key/value pair at the time.

The pattern in the generator for a list or binary comprehension
was processed as an expression instead of as a pattern. That
happened to work because expressions and patterns were translated
in the same way.

In the future we might want to process expressions and patterns
differently.

According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:

   <<>>#{a=>42}

That was not implemented in the OTP 17.

José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:

  http://erlang.org/pipermail/erlang-questions/2015-February/083588.html

This commit implement better errors from map operations similar
to his suggestion.

When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:

  {badmap,Term}

This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.

When a map operation requires a key that is not present in a map,
the following exception will be raised:

  {badkey,Key}

José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.

For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.

If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.

wxFileDialog:getPaths(FD) always return the empty list
on mac when using file dialog.