Lint request: deny_mmx_target_feature

The Intel compiler has an extremely useful warning (https://software.intel.com/en-us/articles/cdiag964) that triggers if MMX code interfaces with x87 code without an EMMS instruction before the x87 code.

Example (playground):

pub fn init(_x: i32);
fn main() {
    unsafe {
        let m0 = _mm_cvtsi32_si64(1);
        let m1 = _mm_cvtsi32_si64(2);
        let mut m2 = _mm_cvtsi32_si64(4);

        m2 = _mm_add_pi8(m0, m1);
        let value = _mm_cvtsi64_si32(m2);

        // Without a call to _mm_empty()
        // this program has UB
        //_mm_empty();
        init(value);
    }
}

Without the call to _mm_empty no emms instruction is emitted, and the program has undefined behavior.

It would be nice if we could add a lint that errors if:

• a crate defines a function with #[target_feature(enable = "...,mmx,...")] - since the function might need to call _mm_empty at the end, or its users might need to do so.
• using #[target_feature(enable = "...,mmx,...")] functions defined by other crates, since that might require the user of those functions from manually calling _mm_empty.

This lint could be improved in the future by suggesting users where exactly calls to _mm_empty() need to be inserted, e.g.:

init(value);
^^^^^^^^^^ error: no EMMS instruction before call

note: Use the EMMS instruction (e.g.  by calling the _mm_empty() intrinsic ) 
after the MMX instructions immediately before the x87 code to restore 
the Floating-point status on the CPU.

Start by reproducing the linked playground example and reading the requested deny_mmx_target_feature behavior in the issue. Trace how Rust and Clippy represent #[target_feature] functions and calls across crates. Done means the lint reports the stated MMX target-feature cases and includes coverage for both locally defined and externally defined functions.