Refactor option evaluation logic

[dsnet]

The previous implementation of options had a single type "option"
that was used to represent either an Ignore, Comparer, or Transformer
and all of the filters relevant to each of them.

We refactor this logic by creating a new type to represent each
fundamental option and each filtering option. Construction of
filtered options is now as simple as wrapping the input option with
the appropriate filter type.

Evaluation of filters now takes a top-down approach where each of
the options now have a filter method and know how to filter themselves
and recursively call filter on the any sub-options.

This approach has the following advantages:

• It is faster because the same filter that was applied to multiple
  options now only needs to execute once.
• Even though this is semantically identical, the implementation more
  closely matches the documented algorithm in cmp.Equal.
• It allows for easier extension of the API to add new fundamental
  and filtering option types.

We also add a String method to each of the fundamental and filter options.
This adds to the complexity of this commit, but helps users with debugging
since printing an option shows the full tree of everything applied.

[neild]

Can/should this function be replaced with a method on the Option interface?

type Option interface {
  apply(vx, vy reflect.Value, t reflect.Type)
}

[dsnet]

It would need to be:

apply(p Path, vx, vy reflect.Value, t reflect.Type) []Option

I don't mind plumbing Path all the time, but requiring every possible applicable option to allocate a slice seems very non-performant. For that reason, evaluate is method on optionEvaluator which only has a single slice to hold all that information.

[dsnet]

We might be able to avoid the performance hit by returning a single Option and relying on Options for the rare case where multiple are applicable. Let me look into this.

[neild]

You could plumb the *state instead of the Path.

This is all internal, so it doesn't matter that much, but it's weird to have an interface implemented by N types and then a big type switch on those types; isn't that precisely what interface methods are for?

[dsnet]

Done.

[dsnet]

This is incorrect. I have to batch all *comparers and *transformers since it is still possible that a later Ignore will take precedence over all these conflicts.

[dsnet]

Fixed. I made it such that filter can return a Options only when there is a conflict.

[dsnet]

I did your suggestion of removing the type switch adding each case as a method.

The reason I was confused was because I thought you were talking about adding that functionality to the filter method, which doesn't work.

I do like the extra bit of type safety this brings, where the return type of filter is applicableOption.