Pinging @elastic/es-search (Team:Search)

A couple notes:

• I introduced a new package org.elasticsearch.index.mapper.flattened. This is not common practice yet, but felt appropriate for more complex like flattened which have various helper classes.
• When moving flattened to its own module, we introduced an unnecessary abstraction DynamicKeyFieldMapper. I had planned to remove this while moving flattened back to core, but ended up keeping it. I now find the abstraction pretty clean, and it may be helpful for other field types we're considering like numeric flattened fields.

do we want to remove x-pack reference in docs/reference/mapping/types/flattened.asciidoc as well?

I think it makes sense to remove this, I pushed a new commit.

Thanks for the review. Before merging I'd like to get more clarity on our overall design (for example when should a field type live in core vs. mapper-extras?) I'll loop back here with conclusions.

I caught up with some others, and the exact design of where different mappers should live is still up for discussion. However I think we can proceed with moving flattened to core -- it has benefits and makes more sense than having it in its own module.