llb: move selector to input

Selector specifies a subdirectory used for the mount in execop. While working on solver-next it has occurred to me that this isn't ideal as it makes it impossible to determine execution path without any execop specific functionality, even though inputs are defined for a generic op. There can be 2 mounts from the same input with different selectors so actually they are different and may be coming completely different cache.

One way to solve it would be to move a selector to the input field of generic llb op. Atm I don't think Edge struct in generic solver needs to be updated. This is relatively clean code-wise but not so nice for LLB as current options are truly generic while a selector path implies that inputs map to a snapshot.

A quick and hacky way to solve the issue and postpone the problem is to just always make a new input in the client if a new mount is created with a different selector. Or we could just add an input for every mount and not deduplicate. But it means that the client knows about a limitation in the backend implementation.

I think the best solution could be to add a filter op and remove selectors completely. But this is a much bigger change.

@AkihiroSuda wdyt?

Start by reading the execop selector handling, the solver-next context, and the generic LLB input and Edge concepts named in the issue. Compare moving selectors to inputs with creating inputs per mount or adding a filter op. Done requires choosing and implementing one design consistently across the client and backend, with validation for mounts that use different selectors.