Handle decoding into embedded structs + fix/change field handling edge case behavior

This PR adds support for decoding into embedded structs:

```go
func TestDecodeEmbedded(t *testing.T) {
	type Dog struct{ Name string }
	var val struct{ Dog } // type has embedded struct

	_, err := Decode(`Name = "milton"`, &val)
	if err != nil {
		t.Fatal(err)
	}

	if want, got := "milton", val.Name; want != got {
		t.Errorf("want Dog.Name == %q, got %q", want, got)
	}
}
```

Without this PR, `val.Name` would be the empty string.

In order to implement embedded struct handling, I copied the field handling code from `encoding/json` with a few deletions. This broke `TestCase` in two areas:

1. A TOML value will only get written to one Go field. Previously, TestCase's struct type checked that TOML `once = "just once"` was written to 2 struct fields (`Once` and `OncE)`. But there was a comment `// wait, what?` so I assumed that this was undesirable. And this PR fixes that behavior.
1. TestCase's struct field `Field` was getting the value `"messy"` not `"neat"`. There was a comment that said `// encoding/json would store "messy" here` and that is indeed what the code in this PR does (although non-deterministically because it's now dependent on map iteration order).

Is the 2nd change undesirable? It's nontrivial to fix it because the loop in `unifyStruct` is now over the `tmap`, so the map iteration order determines whether `messy` or `neat` would get written (in practice it seemed to deterministically write `messy` in my Go environment but that can't be guaranteed).

If it's OK to break backcompat in this 2nd edge case, it seems we get a lot of benefits from using encoding/json's field handling.