log: add caller plugin-id about emitting error events

[daipom]

Which issue(s) this PR fixes:

• Fixes Error event logs should include plugin id #4567

What this PR does / why we need it:
Add caller plugin-id to warning logs about emitting error events.

It would be helpful if we could know what plugin emitted the error event.

We need to care about the compatibility.
This signature change would not break compatibility.

However, I'm concerned that caller_plugin_id has a race condition, although I don't confirm it.
It looks to me that the id can be another plugin-id running concurrently...
It is not the issue with this fix, it is the issue of the existing implementation.

Docs Changes:
Not needed.

Release Note:
Add plugin-id to warning logs about emitting error events.

Example:
From #4567.

<source>
  @type sample
  @id id_sample_not_json
  sample {"data":"this is not json}"}
  tag sample.json
</source>

<filter sample.json>
  @type parser
  @id id_not_json
  key_name data
  <parse>
    @type json
  </parse>
</filter>

<match sample.**>
  @type stdout
</match>

2024-09-11 15:26:26 +0900 [info]: #0 fluentd worker is now running worker=0
2024-09-11 15:26:27 +0900 [warn]: #0 dump an error event:
 error_class=Fluent::Plugin::Parser::ParserError
 error="pattern not matched with data 'this is not json}'"
 location=nil tag="sample.json"
 time=2024-09-11 15:26:27.040657722 +0900
 plugin_id="id_not_json" ### <= This info is added by this PR ###
 record={"data"=>"this is not json}"}
...

[daipom]

However, I'm concerned that caller_plugin_id has a race condition, although I don't confirm it.
It looks to me that the id can be another plugin-id running concurrently...

fluentd/lib/fluent/plugin_helper/event_emitter.rb

Lines 27 to 36 in 51b860b

	def router
	@_event_emitter_used_actually = true
	if @_event_emitter_lazy_init
	@router = @primary_instance.router
	end
	if @router.respond_to?(:caller_plugin_id=)
	@router.caller_plugin_id = self.plugin_id
	end
	@router
	end

[kenhys]

As error.backtrace does not have enough information in this context, so current approach seems reasonable.
(No need to force 3rdparty plugins to fix it)