Build System: Replace GREENPLUM macro, take 2

Jira: MADLIB-666
New k-means: Fixed SQL for compensating for dropped centroids

Jira: MADLIB-522

During the reassignment phase k-means may produce stray centroids. In this case
we sample new centroids using kmeans++. The SQL for this operation had a bug,
which is now fixed. Also, for GP, the SQL needed to be written so that it would
not execute on segment nodes.

I added a unit test for the case where a centroid is dropped (this is easy to
reproduce by simply giving an initial centroid more than once).
k-means random seeding: Fixed query execution problems on PG/GP

Jira: MADLIB-522

The previous query for random seeding gave non-deterministic results (sometimes
0 rows were returned, sometime more). Converting a join to a subquery now
guarantees that the query is executed correctly.
Build System: Replace GREENPLUM macro, take 3

Jira: MADLIB-666

Some files were missing the necessary m4_include.
Utilities: Fix for exec_sql_using(), no longer returns invalid memory

Jira: MADLIB-676

It turns out that the function internal_execute_using_kmeans_args(), which is 
internally implemented by the C function exec_sql_using(), calls the function
datumCopy() to copy the result datum from an SPI query. However, this is done
inside SPI_connect() and SPI_finish(), i.e., in a memory context that will be
destroyed by SPI_finish(). Debug builds of Greenplum intentionally overwrite
deallocated memory, which makes the problem reproducible. The overwritten memory
then caused the datum to have invalid header information, which then causes
subsequent usage of that datum to exhibit undefined behavior.

The solution is to copy the result datum into the "upper executor context", e.g.,
with the function SPI_copytuple().
New k-means: Query tuning

Jira: MADLIB-678

During development I added an "OFFSET 0" to the main k-means query, which improved
PostgreSQL performance by a factor of 3, because it caused a GroupAggregate to be
replaced by a HashAggregate. On Greenplum, however, the OFFSET 0 hurts performance.
Therefore, the OFFSET 0 is now only added conditionally. In the future, it would
be nice to completely get rid of this implicit hint to the planner.
Documentation: Replaced inefficient example of using linear regression

Jira: MADLIB-664

The documentation for linear regression included the following example:
SELECT (linregr(price, array[1, bedroom, bath, size])).* FROM houses;
However both Postgres and GPDB have issues where they will expand the .* out and
end up calling the linregr() aggregate more times than is needed.
Madpack: Remove MADlibSchema variable

Jira: MADLIB-645
Sampling: Include macros in SQL file

Jira: MADLIB-678, MADLIB-584

File sample.sql_in did not include the file containing our predefined macros.
This implied that on Greenplum, the weighted sampling aggregate was defined
without a merge function. This severely impacted performance on multi-node
Greenplum instances.
New k-means: Query tuning

Jira: MADLIB-678

The previous optimization fence "OFFSET 0" was suitable for PostgreSQL only. 
However, an optimization fence is also needed on Greenplum -- with it the innermost
subquery can be sped up by a factor around 2.

An alternative would be moving the innermost subquery that contains the
closest_column calls into a common table expression, but unfortunately that is not
supported by earlier Greenplum versions.

It is unfortunate that we have to use such tricks, but we do not want to forgo a
factor-2 performance improvement.