Allow renaming struct fields using struct tags

[rtpt-erikgeiser]

This PR allows renaming struct fields by adding struct tags. For example, the expession lowercaseField + OtherField can be checked and evaluated with the following struct as env:

type Env struct {
	UppercaseField int `expr:"lowercaseField"`
	X              int `expr:"OtherField"`
}

Closes #13. I drive-by fixed two minor errors in file/source_test.go and gofmt reformatted a few unrelated lines, I hope that's okay for the PR, otherwise I'll revert the unrelated changes.

[antonmedv]

Awesome. Thanks. Will review today.

[andrewbenton]

Could we add an option to modify the struct tag that we retrieve the field name from? Many structs will already have json tags available and it would be nice to take advantage of them without needing to rewrite the struct.

[rtpt-erikgeiser]

In my opinion this is not really idiomatic. I think this kind of problem should probably be solved by a custom Fetcher. However, I think during compilation/checking, structs that implement Fetcher interface are not handled accordingly. Maybe I'm missing something but that's a problem in and of it self. Otherwise it would lend it self to solve custom problems like this. The root of the problem is that Fetcher does not work "the other way around" and provide a list of properties than can be accessed by the Fetch method. Maybe a second interface with ListProperties() could be useful. If a Fetcher then also implements this second interface it could be handled correctly in Env.

So my preferred solution would look like this:

1. expr: Modify Fetcher and Env to handle structs implementing Fetcher
2. user: Write a struct wrapper that implements Fetcher that looks at arbitrary struct tags

---

Anyway, I took a look how we could implement @andrewbenton's suggestion and found that in most places we analyze the tags we currently don't have access to the Config object. We would need to pass it (or only the necessary property) through a few functions to make it work. If both of you think we should do it, I'll happily modify my PR, but I think that it could also be done in future PR or like I described above.

[antonmedv]

I think we can implement it later as separate feature request.

[erkanzileli]

Hi guys, WDYT about this PR? I'd love to use this feature.

[antonmedv]

Will try to review it today)

[rtpt-erikgeiser]

I rebased the branch to resolve conflicts in the test file. Let me know if you have any questions or suggestions for the PR.

[erkanzileli]

Thanks for your effort guys. When do you think there will be a new tag named v1.10.0?

[antonmedv]

Today)