Tweaked LFSR_RATTR_ to take rattr.u

I think passing around rattr.u.datas was undefined behavior, since we
could end up un-unioning it as le32/leb128/lleb128 later.

Taking rattr.u directly in LFSR_RATTR_ means we can't use LFSR_RATTR_ to
create lfsr_rattr_ts from scratch, since rattr.u is not actually a named
type, but we conveniently don't need to do this. And maybe that's a good
thing since it forces the typed variants?

Also renamed rattr.u.data_count -> rattr.u.count now that rattr.u.data
is no longer the default interface in lfsr_rattr_t.

---

Curiously saves a tiny bit of code. If anything I'd have expected a code
increase:

           code          stack          ctx
  before: 35536           2440          636
  after:  35528 (-0.0%)   2440 (+0.0%)  636 (+0.0%)

Author: geky