Support recursive `required` and friends for nested structs

[tmzane]

Something like:

type Config struct {
	Foo string `env:"FOO"`
}

var cfg struct {
	Config `env:"APP_,required"`
}

See the conversation from #52 for details.

[bunyk]

I understood that embedding struct with env tag should prefix everything in embedded struct with that tag. So cfg.Foo would get it's value from APP_FOO, this makes total sense.

But I do not completely understand intention and semantics of required. It is for cases when users would want to have all the fields required and would want to just type that once? What would happen if with the following:

type Config struct {
	Foo string `env:"FOO,required"`
	Bar string `env:"BAR"`
	Baz string `env:"BAZ" default:"some value"`
}

var cfg struct {
	Config `env:"APP_,required"`
}

required on the root will make all the fields required and discard default? Or will just make Bar required, and Baz will keep it's default? Or in general, having a path of nested fields like A_B_C_D, if any of the fields has required variable A_B_C_D would be required?

[tmzane]

It is for cases when users would want to have all the fields required and would want to just type that once?

Yes. Or just a group of variables:

type Config struct {
    // all DB_* variables are required:
    DB struct {
        Host string `env:"DB_HOST"`
        Port string `env:"DB_PORT"`
    } `env:",required"`
    // the rest of the fields...
}

required on the root will make all the fields required and discard default?

Currently, marking a variable as both required and default is an error. I think it should be the same in this case. We could make that a leaf would take precedence over the root, thus, overriding the root's modifier, but it seems poorly readable to me. An experimental PR is needed to see how good it works.

having a path of nested fields like A_B_C_D, if any of the fields has required variable A_B_C_D would be required?

Yes. In general, I'd like it to be a convenience option, so users could specify a modifier just once. Just like prefixing nested structs that you implemented recently.