Refactor, enhance and fix bugs in ScanTemplate

[jhart-r7]

This started off as a simple fix for working with scan templates that didn't have disabled checks, types or categories and turned into more than that. I've:

• Made all of the check/category/type enabled listing methods consistently not fail if the template didn't have any explicitly enabled. IOW, fixed this:

irb(main):021:0>  t2 = Nexpose::ScanTemplate.new('test')
=> #<Nexpose::ScanTemplate:0x007fb0be248828 @xml=<UNDEFINED> ... </>>
irb(main):022:0> t2.vuln_checks
NoMethodError: undefined method `elements' for nil:NilClass
    from /home/jhart/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/nexpose-2.0.2/lib/nexpose/scan_template.rb:407:in `vuln_checks'
    from (irb):22
    from /home/jhart/.rbenv/versions/2.2.1/bin/irb:11:in `<main>'
irb(main):023:0> t2.checks_by_type
NoMethodError: undefined method `elements' for nil:NilClass
    from /home/jhart/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/nexpose-2.0.2/lib/nexpose/scan_template.rb:355:in `checks_by_type'
    from (irb):23
    from /home/jhart/.rbenv/versions/2.2.1/bin/irb:11:in `<main>'
irb(main):024:0> t2.checks_by_category
NoMethodError: undefined method `elements' for nil:NilClass
    from /home/jhart/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/nexpose-2.0.2/lib/nexpose/scan_template.rb:321:in `checks_by_category'
    from (irb):24
    from /home/jhart/.rbenv/versions/2.2.1/bin/irb:11:in `<main>'

• Added similar functionality for disabled
• Renamed the methods to be more consistent and obvious, adding warnings for the old methods which should be dumped when 3.x happens.
• Unit tested everything

[asalazar-r7]

usually we alias the old names if it's just a name change.

[sgreen-r7]

personally I'm kinda against an alias in this case, just because it will specially make people aware that they're asking for enabled vuln checks.

even though there's no real difference between vuln_checks and enabled_vuln_checks; we'll be helping out readability and "common sensuousness" of what is actually happen. if we alias vuln_checks while we have enabled and disabled and users dont know it's aliased, then it would be reasonable to assume that vuln_checks will respond with both enabled and disabled.

[jhart-r7]

I agree with @sgreen-r7's reasoning on not using alias in this case. Since the method name will be going away, is this considered a major enough change that we need to bump to 3.x? Or 2.1.x?

[gschneider-r7]

Backwards-incompatible changes (method names and signatures, etc) will be major version so 3.x.

[erran-r7]

I agree with @sgreen-r7's reasoning on not using alias in this case. Since the method name will be going away, is this considered a major enough change that we need to bump to 3.x? Or 2.1.x?

@jhart-r7 @gschneider-r7 @sgreen-r7 How about adding a deprecated tag to the "alias" and maybe even logging a message?

[gschneider-r7]

The behavior is not quite the same, though, right? So aliasing it with a warning doesn't seem like the best solution.

[jhart-r7]

Correct. The behavior is not the same.

Lets just do 3.x. It is easier and more correct.

[gschneider-r7]

Separately from this PR, we could have another 2.x release that include a deprecation warning for these methods (and any others we plan to change for 3.0). Not sure how useful it is really, but might be a nice gesture.

[jhart-r7]

I've redone this to make it better for users of this gem and to ease landing, removing the need to go to 3.x for now. After this lands, #184 could be updated to remove the three warnings.

[asalazar-r7]

Looks good. Ship it!