Allow mj-include to have children

[sgrimm]

Is your feature request related to a problem? Please describe.
Maintaining a set of MJML files that are identical except for the contents of a small number of child elements currently involves an unfortunate amount of boilerplate in the top-level MJML. You end up with a lot of MJML files that look like

<mjml>
    <mj-include path="./head.mjml" />
    <mj-body>
        <mj-include path="./company-logo.mjml" />
        <mj-section>
            <mj-column>
                <mj-include path="./greeting.mjml" />

                <mj-text>...Text that is specific to this particular message...</mj-text>

                <mj-include path="./epilogue.mjml" />
            </mj-column>
        </mj-section>
        <mj-include path="./company-contact.mjml" />
    </mj-body>
</mjml>

Describe the solution you'd like
A tag that can be used in an included file that inserts the contents of the <mj-include> tag that caused the file to be included. So instead of the above, the top-level MJML file would look something like

<mjml>
    <mj-include path="./skeleton.mjml">
        <mj-text>...Text that is specific to this particular message...</mj-text>
    </mj-include>
</mjml>

and skeleton.mjml would look like the original file except that instead of the <mj-text> tag, there'd be a new tag to insert the content of the top-level file's <mj-include>.

I am not asking for full templating support or anything like it. No conditionals, no named attributes! But instead, a more limited-scope feature where the DOM tree under the parent <mj-include> can be inserted verbatim from within the included file.

Describe alternatives you've considered
Generating MJML from templates would work. That ends up being a lot of levels of indirection, especially given that my MJML files are used to generate FreeMarker templates: I'd be rendering a template (my initial file) to a template (the MJML) that would then get rendered to a template (FreeMarker) that would get rendered to the final HTML.

Writing a custom component is another option, but then we lose the ability to let nontechnical people edit the messages in an MJML editor. (The first option also has this problem.)

[iRyusa]

I'm confident that such thing would be use by users to bypass the fact that MJML doesn't support variable. We really stand behind what we said in #1630, i'm closing