Refactor internal API

[jwoertink]

Fixes #23

This is a pretty big refactor and breaking change that moves the internal methods from instance methods to class methods.

This changes up quite a few things.

• Reverts the task_name macro back to name like it was before, but keeps the generated method as task_name
• Changes the generated summary name to task_summary
• Summary is now optional
• Changes the help_message to task_help_message
• Moves all of these from instance methods to class methods

Because Crystal treats macros like class methods, and arguments on macros are always optional, you can't really have a class method with no args be the same name as a macro. So to avoid a compilation error, the methods are named different from their macro counterparts.

Old interface

class My::Task < LuckyTask::Task
  name "new.name"
  summary "Here is my description"

  def help_message
    "my custom help message"
  end

  def call
    # do stuff
  end
end

task = My::Task.new
task.name #=> "new.name"
task.summary #=> "Here is my description"
task.help_message #=> "my custom help message"
task.print_help_or_call(["-v"])

New Interface

class My::Task < LuckyTask::Task
  name "new.name"
  summary "Here is my description"
  help_message "my custom help message"

  def call
    # do stuff
  end
end

My::Task.task_name #=> "new.name"
My::Task.task_summary #=> "Here is my description"
My::Task.task_help_message #=> "my custom help message"
My::Task.new.print_help_or_call(["-v"])

[matthewmcgarvey]

The issue you saw with trying to use a class function that has the same name as a macro, I wonder why that doesn't affect anything when the macro is name. Seems like an import class method that core Crystal would call on the class in cases like errors and stuff.

[mdwagner]

Looks good to me! I'm not seeing any glaring issues.

[jwoertink]

@matthewmcgarvey it turns out that using name does have the same affect if the name macro also generates a class method name, but it doesn't have that affect when it does anything else... I tried to see how Crystal handles that, but it looks like they may make special considerations for that https://github.com/crystal-lang/crystal/blob/fb92a1e94669fd736c40d7b93611f43d5db5e028/spec/std/class_spec.cr#L71-L74

[jwoertink]

Pulled this in to Lucky and everything seems to run ok. 1 weird issue that came up was we have this method https://github.com/luckyframework/lucky/blob/ecb57b1e8f104567b9615eee3b29ca8345753cb0/tasks/routes.cr#L61-L68 which gets called both in the instance level output and the help message... With the help message moving to a class method, these aren't as "shareable"... Still doable, but just a little moving around.

Otherwise it all feels fine