ARROW-1703: [C++] Vendor exact version of jemalloc we depend on

[xhochy]

No description provided.

[wesm]

+1 pending rebase. However, do we want to enable this in one of our Travis CI build entries?

[xhochy]

I'm not sure if we have a free matrix entry anymore where we would be able to activate it again. I would like to (gradually) reintroduce jemalloc as the default again but we also should keep jemalloc-free builds in our test matrix.

[wesm]

Perhaps we can do it in one of the Linux builds for now. I'll merge this and we can deal with the reintroduction as the default in a separate patch

[wesm]

N.B. The problem with this vendoring strategy is that updates to jemalloc will bloat the repo size, where the vendoring procedure used in Redis and other projects would not. So if we end up needing to update jemalloc more than once in the future, we might check in the raw source directory so that incremental diffs don't cause a significant increase in repo size

[xhochy]

I don't expect that we will update jemalloc often. Hopefully, we can use the stable 5.x release series soon and then use official builds everywhere.