See whenever you find abort, it becomes more easier to answer the question.
If in any transaction, abort is given it simply means that by the end that( transaction having abort) transaction will roll back and so consider it doesnot exists when answering for conflict serializable, view serializable or serializable. And then since only one transaction remains it will be conflict serializabe, and if it is conflict serializable then it is both view serializable and serializable.
So, all the three parts above are C.S, V.S and Serializable.
In recoverable, we just check if the transaction which is reading the value of a data item( X here) which is written by other transaction, is commiting only after the transaction writing the value has committed. In (1) part there is no such dependency of read write so nothing to check for commits thus recoverable. In (2), T2 reads the value of X written by T1 and it doesnot commits before T1 has committed so it is recoverable but in (3), T2 is reading the value of X written by T1, so T2 must commit only after T1 commits, but it doesnot happens so (3) is not recoverable.
Now, if any schedule is not recoverable, it is cascading and not strict. So (3) is cascading and not strict.
In cascadless, if Tj is reading the value of a data item written by Ti, then Ti must commit the value before Tj reads it. If there is no such dependency, then also it is cascadless. Here, in (1) no dependency exists so it is cascadless. But in (2) and (3) there is dependency and T2 is reading the value written by T1 before T1 actually commits so it is cascading. And if it is cascading it is not strict.
In strict, a value written by a transaction Ti cannot be read or write both by any other transaction until Ti commits it. But in (1), between two w(x) there is no commit by T1 so it is not strict.