Feat: ECS compatibility support

[kares]

also made LS::Environment's pattern_path optional

• [x] needs logstash-mixin-ecs_compatibility_support 1.0
• [x] spec different named captures when in ecs (v1) mode
• [x] target an ecs branch instead, since this is going to be an effort at logstash-patterns-core
• [x] should require (new) patterns core >= 4.3.0 https://github.com/logstash-plugins/logstash-patterns-core/pull/297
• [x] changelog entry + bump
• [ ] setup overwrite => [ message ] in ECS mode due patterns that extract an inner "message" field NOOP atm - our planned approach seems to be to make sure "event.original" is filled and "message" not being set

POST: cleanup patterns core depending on this branch as a gem dependency

resolves #157

[kares]

@yaauie when you get a chance - the loading part (this PR) should be quite simple. what I am struggling with is what will be the best (new) layout at logstash-patterns-core :

• rename patterns directory -> patterns-legacy or do we want to keep patterns as is ? user might think this is still the place to look for pattern definitions - believe we should rather rename despite the cost (blowing all PRs)
• create patterns-v1 (or patterns-ecs-v1) for the ECS 1.x compatible copy
• adjust LogStash::Patterns::Core.path (for a new major 5.0) to accept a selector:

    def path(selector = :legacy) # no-arg default needs to work as before!
      # since the grok filter gem does not have a upper bound on the dependency :meh: 
      base = ::File.expand_path('../../..', ::File.dirname(__FILE__))
      case selector
      when :v1
        ::File.join(base, 'patterns-v1')
      when :legacy
        ::File.join(base, 'patterns-legacy')
      else
        raise "..."
      end
    end

[yaauie]

On directory layout, I'm okay with your proposed hyphenated renames, but a nested structure could give us the opportunity to inject documentation. I agree that it's worth breaking the in-flight PRs (but also that we really need to expend some effort to bring some of those suggestions forward).

patterns/
  README.md <-- define the path forward and how a set of patterns is loaded by default
  legacy/*
  ecs-v1/*
  ecs-v2/*

---

On adding a selector to LogStash::Patterns::Core#path, I see no reason to make this a major, so long as it continues to work as-is when no selector is provided.