Creates PIG Gradle plugin

[RCHowell]

Issue #, if available:

#102
#5

Description of changes:

A Gradle plugin for PIG which generates a task for each type universe in each source set.

Usage

plugins {
    id 'pig-gradle-plugin'
}

sourceSets {
    main {
        pig {
            // in addition to the default 'src/main/pig'
            srcDir 'path/to/type/universes'
        }
    }
    test {
        pig {
            // in addition to the default 'src/test/pig'
            srcDir 'path/to/test/type/universes'
        }
    }
}

pig {
  target = "kotlin" // required
  namespace = ... // optional
  template = ... // optional
  outDir = 'build/generated-sources/pig/<sourceSet>' // default
}

Missing

• Add dependency on runtime library to project
• I have a README, but it's not in the root. Should be in the root and wiki.

To Improve
How the plugin dependency is consumed in the pig-tests package.

// It is non-trivial to depend on a local plugin within a gradle project
// The simplest way is using a composite build: https://docs.gradle.org/current/userguide/composite_builds.html
// Other methods involved adding the build/lib/... jar to classpath, or publish to maven local
// By adding the plugin as a dep in `pig-tests`, I cannot use an included build of `pig` in the plugin
// Hence it's much simpler to use the latest published version in the plugin

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[johnedquinn]

Had a single comment regarding the plugin linking via Gradle. Beyond that, the rest of the PR looks great! Really awesome feature added in a small amount of code.

[johnedquinn]

We discussed in-person, but just leaving the note here as well for others to discuss. Might be worth looking into alternatives to hard-coding the version. We discussed referencing the JAR if possible. I tried pulling this and going another route but had some issues. Anyways, glad you found a way to make it work, but would be nice to remove the hard-code!

[RCHowell]

The plugin, runtime, and generator should all be a single gradle project. The issue here is caused by the pig-tests package which, as is, should not be in the main pig gradle project. The pig-tests needs to be fixed to use the generator directly rather than the executable. Executable/plugin usage should be in a separate "pig-example" project which would avoid these oddities. Right now, example usage and testing are intermixed. #130