tls1prf: require callers to pass in the result buffer

[qmuntal]

This PR updates TLS1PRF to accept a byte slice parameter where to write the output. This avoids allocating a new slice on each function call and integrates better with the standard library, which expects the PRF to update an already existing slice: https://github.com/golang/go/blob/2f0b28da1900909a2c3ddf646bb508fc7effb8f2/src/crypto/tls/prf.go#L68.

To make is clear, the current code would have to be integrated like this:

func prf12(hashFunc func() hash.Hash) func(result, secret, label, seed []byte) error {
	return func(result, secret, label, seed []byte) error {
		if backend.Enabled && backend.SupportsTLS1PRF() {
			out, err := backend.TLS1PRF(secret, label, seed, len(result), hashFunc)
			if err != nil {
				return fmt.Errorf("crypto/tls: prf12: %v", err)
			}
			copy(result, out)
			return nil
		}
                ...
	}
}

While with the new approach, it would like this:

func prf12(hashFunc func() hash.Hash) func(result, secret, label, seed []byte) error {
	return func(result, secret, label, seed []byte) error {
		if backend.Enabled && backend.SupportsTLS1PRF() {
			err := backend.TLS1PRF(result, secret, label, seed, len(result), hashFunc)
			if err != nil {
				return fmt.Errorf("crypto/tls: prf12: %v", err)
			}
			return nil
		}
                ...
	}
}

[ueno]

Makes sense to me; I thought it might be good to align with other KDF API (e.g., either crypto/pbkdf2 or crypto/hkdf), though TLS1PRF is purely for internal use, so it would be better to align with the actual usage in crypto/tls.