updated go version of the builder Dockerfile

[sio4]

Oops! my force-push, after rebasing and adding one more commit to the original brach, made the pr #148 could not be reopened. :-( Sorry @paganotoni. I tried to keep your commit and PR and others' commit too but it was not perfect.

Comment from the original PR:

This PR changes our builder Docker images to be based in Go 1.18.

This is a part of gobuffalo/buffalo#2264.

All current tests for the major packages (which are used for buffalo core, buffalo CLI, pop, and the generated app by default) are passed and it looks like the generated app also working fine with g1.18 and the recent version of packages.

I think it is time to update Dockerfile for the builder.

By the way, IMO, I would like to keep the code compatible with 1.16 for a while (I mean we don't need to proactively remove compatibility code) since I think there are many users who still using 1.16 in their production. (I hope our policy for the go version could be a kind of "we officially support the last two versions of go, but it could be ok using a few more previous versions")

(two of unrelated module update is also included)

[fasmat]

By the way, IMO, I would like to keep the code compatible with 1.16 for a while (I mean we don't need to proactively remove compatibility code) since I think there are many users who still using 1.16 in their production. (I hope our policy for the go version could be a kind of "we officially support the last two versions of go, but it could be ok using a few more previous versions")

With the change from packr to embed I had to make some changes specifically for 1.16 that are not necessary any more with 1.18: dot-files, pattern matching, etc. (https://tip.golang.org/doc/go1.18#minor_library_changes) It would be possible to do some cleanup in this regard if we drop support for 1.16, even more in a few months when we drop support for 1.17.

1.17 added new stuff to the standard library that would be great if we could use it: io/fs has a new FileInfoToDirEntry function that would again allow for simplification of existing code.

If we want to introduce generics at some point in the future within our codebase we will have to drop support for 1.16 and 1.17 completely. Imho it would be cool do drop all the places where we are currently using interface{} and use generics instead. Dropping support for 1.16 is the first step towards being able to use them.