Ensure rounding flag is properly emitted on some x86 floating point instructions

[plafosse]

Summary

• Add IL_FLAG_C1 as an explicit output to x87 intrinsics that use IL_FLAGWRITE_X87RND: F2XM1, FBLD, FSIN, FCOS, FSINCOS, FPATAN, FPTAN, FSCALE, FYL2X, FYL2XP1
• Return il.Undefined() for C1 with IL_FLAGWRITE_X87RND — the rounding direction flag is runtime-dependent and can't be computed at lift time, so Undefined correctly invalidates prior values of C1 without claiming a false constant
• Update intrinsic output type lists to include the additional bool output for the rounding flag

[rssor]

undefined we've mostly used as a block-ender top level instruction, letting it stay as unimplemented (which it is, because we can't really) might be fine? unless this is just to work around the fact that unavoidably adds low-value tags for unimplemented

undefined means (or at least used to) 'actual problem', and unimplemented was more 'benign/incalculable'

[rssor]

this is also why there's unimpl/unimpl_mem as well: they're meant for use as value-producing exprs that aren't actually harmful on their own. i wonder if we'd be better off just taking an instruction attribute bit to suppress tags so that it's safe for architectures to use unimplemented without adding tags every time we see one, since unimplemented is supposed to be safe to use. (or, stretch goal: suppress unimplemented tags by default since they aren't actionable for almost everybody who isn't working on an arch plugin)

as it is, we've kind of forced ourselves into running away from using the intended instruction because the tag makes it look like 'unimplemented' means 'haven't gotten to it yet' and not 'we need to clobber this with a stand-in expr, because there may not ever be anything sane to replace it with'. as it is, we're drifting towards repurposing another instruction just to get away from how we add tags (I think).