Initialize include-files as Jekyll objects

[ashmaroli]

Summary

This PR optimizes the processing of include files.

Currently, include files are located and read into memory for each call to the tag's render method. Though the parsed include templates are cached, they're cached to a given Liquid context. So, the file warrants a re-parsing when the context changes.

With the proposed changes, include files are initialized into new Jekyll::Inclusion core objects. The actual file-contents and its parsing are deferred until necessary (during the render calls) and subsequently cached until next regeneration.
To maintain backwards-compatibility with Ruby API, the rendering is now handled by a new (temporary) subclass of Tags::IncludeTag.

Does not need documentation updates or tests since there are no discernible changes to either Ruby API or API exposed for Liquid templates.

[DirtyF]

Manual testing does not show any build time improvement on our docs.

[ashmaroli]

Memory profile (on AppVeyor)

--- master https://ci.appveyor.com/project/jekyll/jekyll/builds/32641386/job/nvd9jag59n0u2y3b
+++ PR     https://ci.appveyor.com/project/jekyll/jekyll/builds/32685467/job/vexmf42xsrltwa0p

- Total allocated: 357.98 MB (2873621 objects)
- Total retained:  19.76 MB (109571 objects)
+ Total allocated: 351.86 MB (2853141 objects)
+ Total retained:  19.78 MB (109651 objects)

[DirtyF]

I'll defer to @mattr- if it's worth the "future" breaking change, hard to evaluate the gain from the only memory consumption results on large sites.

[ashmaroli]

the "future" breaking change

Technically, it need not progress into a breaking change if we or the maintainers at the time don't want to, but I placed the comment to deter plugin authors and for the maintainers in the future to have a plausible less-messy option.

[mattr-]

Related to breaking changes: As long as we're not modifying the base contract of the API, then there's no reason we can't make wholesale changes under the hood, as long as the same API works between versions. I don't see anything to worry about with this PR, unless I've misunderstood the issue somehow.

[ashmaroli]

@mattr- I've dropped the idea of using a relative_path for these instances entirely.

Concerns addressed..

[DirtyF]

Notable gain if we compare current build time with master.

[ashmaroli]

@jekyllbot: merge +dev