[silgenlvalue] NFC refactorings.

[gottesmm]

I am preparing this code for eliminating the NominalType peephole in RValue emission for member_ref_expr. The key way I am planning on doing this is by teaching LValue emission to use LValue components for project operations instead of evaluating each of the member_ref_expr as individual RValues.

These two commits take us on the way to that world by:

1. Adding a small helper for generating a tuple child LValueData.
2. Moving the creation of the creation of the ValueComponent into visitRecInOutBase instead of doing it upon returning to visitRec from said function. This will enable me to add additional components to whatever LValue is returned from visitRec from within visitRecInOutBase. For instance, I could add a StructElementComponent.

[gottesmm]

@swift-ci smoke test

[slavapestov]

Should Sema emit all property accesses as lvalues inside LoadExprs?

[gottesmm]

@slavapestov Elaborate?

My main concern here in general is that we need to draw a sharper line when we go in between the "normal cleanup world" (RValue emission + others) and "formal evaluation cleanup world" (SILGenLValue).