Inline all the things! 🎨

[karwa]

#92 introduced quite a serious performance regression by refactoring inlinable code in to a helper function which was only usable from inlined code, but not itself inlinable. The first commit corrects this.

Upon further inspection, I noticed a pattern - that all internal functions seemed to only be @usableFromInline and not @inlinable, whereas their public siblings were all @inlinable. Inlining is critical for exactly this kind of code - lazy wrappers and collections and so on, and especially when they are generic. For instance, how is the client's instance of the compiler supposed to be able to optimise Chain, when the implementation of offsetForward is hidden from it?

So the second commit inlines basically everything that was previously @usableFromInline.

Additionally, I would strongly recommend setting up a benchmark suite, so that small refactorings don't cause huge performance regressions in future. I have some concerns about adding swift-algorithms as a dependency for my performance-sensitive project, and a benchmark suite which ensures at least stable baseline performance would help convince me that it's safe to rely on this project.

[kylemacomber]

@swift-ci please test

[natecook1000]

Thanks for chasing these down, @karwa! Agreed that this is a better default, and that we do eventually want a wait to keep benchmarks for this package.