current logic operator can refuse to build cop task type physicalization

## Enhancement
previously, the old code which is still inherited today shows that, we will refuse build cop task for almost every opearator, but we could still see a lot of projection and selection pushed down to cop[tikv], isn't it?
https://github.com/pingcap/tidb/pull/3577/files#diff-9140ee5cb1afea2289fe985745119d022f7c53edd96f4514000f725f83507b34R477

the reason is that, the attach2Task didn't follow the required prop which must be the ROOT above, Example, in the above case, we can only admit a ROOT type projection/selection there, when we attach the projection/selection to a COP child task which may be converted from datasource, those required ROOT type projection/selection can also be attached into the cop characteristic COP task as well, wrapped as COP task and returned above.

Yes ROOT type can be mutated as COP/MPP/ROOT in each operator is reasonable, each one of the three is a always acceptable. But if ROOT type will cause projection and selection can not propagate down the cop and mpp required task type, but root, it works, but not that reasonable.

say op2 is that projection/selection here, it can't accept COP type, but ROOT type, while since child can always generate COP task type, the op2 here can also attach into this kind of COP type as well.

leave this issue for current code logic reminder