Feat: ECS compatible default behavior

[kares]

This PR makes the plugin compliant with ECS by simply using a target => default which makes the plugin act as an in place translator (source = target field).

Some minor tweaks along the way:

• target is replacing destination to align with plugin convention
• in case of @field == @target (ECS default) we no longer require to configure overwrite => true
• CI :green_circle:
• review error handling

closing https://github.com/logstash-plugins/logstash-filter-translate/issues/86

[kares]

Separately, is the deprecation/migration from field to source to align with naming conventions of many other plugins worth pulling into the scope of this PR?

Addressed, let me know how it looks - the only downside we can not rely on config :source, ... :require => true

[kares]

@yaauie given that we made the old field and destination non supported in ECS mode (in favor of source and target) means we actually make user legacy pipeline transitions a bit more demanding - they can not simply just flip a pipeline switch but they will need to update to using the new names. I think it's acceptable but still wanted to double check.

[yaauie]

we actually make user legacy pipeline transitions a bit more demanding - they can not simply just flip a pipeline switch but they will need to update to using the new names. I think it's acceptable but still wanted to double check.

You are absolutely right. I was using it as a forcing function and that is certainly an increase of friction that is not needed.

You should be able to cherry-pick ced4162e0cd296b5444b685c05c1f1556715205f from my fork to bring the field/destination fall-through up into ECS

[kcm]

For what it's worth, in the field we ran into a customer that mistakenly thought the 3.3 and 4.0 versions in the deprecation message were (ancient) Logstash versions. I'm not sure if it's worth clarifying this further, at this point.