WL#11150: Add <component> to error log messages by default

Add  to error log messages by default.

 must have one of three values: [Server], [InnoDB], [Repl]

 will be placed between [] and 

Example:

2017-09-07T08:15:04.448690Z 0 [Warning] [003786] [Repl] No argument was provided
to --log-bin, and --log-bin-index was not used; so replication may break when
this MySQL server acts as a master and has his hostname changed!! Please use
'--log-bin=vide27-bin' to avoid this problem. 

1 Func-Req

1.1  Traditional log

The traditional log shall feature another new field. This field will appear 
between '['  ']' and '['  ']'.

The value of this field should be "InnoDB" (for errors thrown in the InnoDB 
storage engine proper), "Repl" (for those thrown by the replication subsystem), 
or "Server" (otherwise).

As with the new error-number field (WL#11009), this should result in legacy tools 
that are not aware of this new field interpreting it as part of the human-
readable error-text. Those tools will therefore hopefully "fail" gracefully, that 
is, being unaware of the new format should not prevent "legacy" fields from being 
read correctly. This is however not something we can test and verify as those 
tools are not under our control; therefore, there will not be a non-functional 
for this.

I-1  Semantics

NO CHANGE

I-2  Instrumentation

NO CHANGE

I-3  Error and Warnings

NO CHANGE

I-4  Install/Upgrade

NO CHANGE

I-5  Commercial plugins

Minimal code/behaviour change: logged errors now include the new field, and one 
of the three specified values.

I-6  Replication

Minimal code/behaviour change: logged errors now include the new field, and one 
of the three specified values.

I-7  XProtocols

NO CHANGE

I-8  Protocols

NO CHANGE

I-9  Security

NO CHANGE

I-10  Log Files

YES: The traditional error log file will have a new field; this field is non-
empty and has one of the following 3 values; "Repl", "InnoDB", or "Server". It 
is inserted between the error-number field, and final field containing the 
human-readable error message.

I-11  MySQL clients

NO CHANGE

I-12  Auth plugins

Minimal code/behaviour change: logged errors now include the new field, and one 
of the three specified values.

I-13  Globalization

NO CHANGE

I-14  Configuration

NO CHANGE

I-15  File formats

NO CHANGE (see log files for that)

I-16  Plugins/APIs

Using the APIs will remain unchanged; some of the wrappers have however been 
updated to automatically set labels compliant with this spec.

I-17  Other programs

NO CHANGE

I-18  Storage engines

InnoDB: Minimal code/behaviour change: logged errors now include the new field 
with a value of "InnoDB" when reported in InnoDB proper.

I-19  Data types

NO CHANGE

I - New code

a) Which label is used for a given call can be controlled by a dedicated 
particle 
in the error logging code, subsys(). (This nomenclature is chosen to avoid 
confusion with the component framework.)

b) This particle will automatically be added by the new standard call, LogErr(), 
and its plug-in related variants.

c) Its value is controlled by a #define, LOG_SUBSYSTEM_TAG.
This is distinct from LOG_COMPONENT_TAG which is primarily intended for 
components as defined in WL#4102, "Service registry and component 
infrastructure", and uses its nomenclature. Plug-ins that use the component API 
for error-logging (as opposed to the legacy plug-in API) must also set 
LOG_COMPONENT_TAG to their own name if they wish to utilize that 
LogPluginErr*() family of macros. If LOG_COMPONENT_TAG is undefined,
only LogEvent() and LogErr() will be available.
See also WL#9651 and WL#9342 (filtering error-log events) for working
with these key/value pairs and WL#9323 (structured error logging).

d) This #define will be set up automatically for the cases laid out in the WL:

da) "InnoDB" will be set up for the InnoDB storage engine as a -D define in the 
SE's CMakeList.

db) "Repl" will be set up if the common include, log_shared.h, identifies the 
current source file to be starting with the prefix "rpl_".

dc) A source file can set this value individually where needed.

dd) Where none of the above applies, the logging core is reached with no value 
set; it will then use "Server" as the default value.

e) For rare corner-cases where LogErr() and friends are not suitable or 
sufficient, engineers may use the LogEvent() call that is wrapped by the 
aforementioned calls. In these cases, they may need to manually include the 
subsys(LOG_SUBSYSTEM_TAG) particle where not the default, "Server". These cases 
are expected to be rare.

II - Clean-up

Some of the code base currently sets up these tags with a higher granularity 
than requested; these cases need to be aligned with the new requirements. 
Specifically, calls from plug-ins or components should be tagged with one of the  
three values specified above ("Server", "Repl", "InnoDB"); usually "Server" 
(which is applied if the component does not specify another value).
Specific plug-in/component names where given must not appear in the context of 
these labels, but may as before appear in structured writers as information in 
addition that specified in this WL, or may appear in the actual error-message 
field itself in the traditional format, either as part of the message string 
itself (as registered in errmsg-utf8.txt), or as part of a template added by a a 
wrapper (e.g. LogPluginErr() / LogPluginErrMsg(), which use a prefix of "Plugin 
xy reported" to keep previous semantics -- see WL#9344 and friends, 
4eac7bc40882320e3d4d961c49f665021573b6b1). The following would therefore be 
considered compliant:

[MY-012356] [Server] My message here
[MY-123457] [Repl] Team rpl's message here
[MY-013458] [InnoDB] Team Inno's message here
[MY-654321] [Server] Plugin myPlugin reported: 'Some plugin's message here'