No, TRESOR was never integrated into the Linux kernel. It is specific to the x86 architecture, and requires AES-NI in order to not have a pretty nasty overhead. Due to the limited size of DR registers where the key is stored, it cannot store and precompute round keys (a common AES optimization), and thus must recompute them every single time. This isn't much of a problem if you have AES-NI, but it can be a pain if you don't. Linux devs don't like adding a feature that's a hacky workaround to a specific forensic technique applied against a hardware bug, especially when the mitigation only works well on newer x86 CPUs with AES-NI.
In addition, it prevents setting hardware breakpoints. Now, people usually set software breakpoints when debugging, because you can only set a maximum of 4 hardware breakpoints at a time, but some people cannot use software breakpoints because of the lower performance. TRESOR, because it uses all DR registers, requires the kernel tell userland that the number of DR registers is 0, and block all access to them for security reasons.
Regarding whether or not it solves the problem of cold boot attacks, the answer is partially. It completely mitigates the issue of stealing encryption keys from memory, but it does not encrypt the rest of memory. If you open a super secret file, it will stay in your page cache for a while. If your system is cold booted right then, the majority of your disk may be protected, along with your AES key, but all the files in your cache, including that super secret file, are exposed. The same goes with the rest of the data in RAM, like pages open in your web browser, etc.
