Hoist base Slice class into ProjectRazor::Slice

All the common slice functionality was held in the `ProjectRazor::Slice::Base`
class, which was quite confusing when you consider that every implementation
is-a slice, and they are used in compliance with the Liskov substitution
principal by the rest of the system.

This rewrites the code to implement all the functionality in a base class,
with subclasses nested below it.  There is no change to the capability of the
system, just less surprising code structure.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Pass arguments rather than using global member variables

The main razor script used member variables at global scope where a simple
function argument would do.  This eliminates one of those variables.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
More arguments rather than global variables

This eliminates another global (member of Object) variable from Razor.
There should be no functional changes, just cleaner code.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Perform file to constant translation the Ruby way

The slice definition used some simple meta-programming to transform a slice
name into a Ruby constant, associated with the appropriate class, as well as
to identify the set of available slices by mapping through files on disk.

It didn't quite match the Ruby model for file to constant translation, though,
which made for some surprising class names - it assumed that `.capitalize` was
sufficient, while really you need to split on `_` and rejoin the components
after mapping leading caps across them.

There should be no functional changes from this, just cleaner code.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Simplify condition handling around missing slices

Now, rather than doing a whole lot of pre-testing of slices to determine if
they are valid we just go right ahead and try and use them.  When they are
found missing we report that nicely, and otherwise carry on.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Remove "slices loaded" and associated global state

The code around "loaded" slices was a bit of a mess: it actually looked to see
what was available on disk, not just loaded.  It also used global state to
pass data between methods that were separated in time, but not
actually decoupled.

With the rework of condition handling for missing slices we can eliminate most
of that, then inline the "discover available slices" facility into the method
that prints available slices.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Move CLI handling into a class, not a script

This moves the command line handling and dispatch out of the `bin/razor`
script and into a class.  There is no current functional change, but rather a
cleaner separation of objects.

This opens the door to better testing of the command line dispatch related
code, to ensure that it behaves correctly, than the script permitted.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Refactor the CLI handling to be a little cleaner

This is part of a series of refactorings that should have no externally
visible effect, but which make the CLI handling substantially
cleaner internally.

This replaces an init method with object initialization.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement Puppet Labs best-practice version handling

Instead of a configuration, or source, file containing a hard-coded version
Puppet Labs uses a pair of methods to determine the version of software:

In the case of pre-release software, software installed from git, or nightly
builds we strongly prefer to use the results of `git describe` to identify a
robust and reproducible version number.

In the case of release software we burn the release version string into the
final product, typically by modifying a `lib/${project}/version.rb` file that
defines a `Project::VERSION` constant that third parties can use.

As with our standards, `require "project/version"` doesn't cause the entire
suite to be loaded, so you can use that to make version-specific decisions
about interacting with the rest of the software suite.

Many of those capabilities are not presently used, or usable, with Project
Razor, but following standards ensures we can do that as we export more usable
code-level APIs.

It does improve reporting of the version that happens for current git
installations of the software.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #232 from daniel-pittman/maint/master/cleaner-code-for-a-cleaner-life

Cleaner code for a cleaner life!