[Toybox] getfattr is insane

[Rob Landley]

So setfattr doesn't accept key=value pairs, but instead -n key with
optional -v value. Meaning you can only set one per invocation,
because... [jazzhands]

But getfattr is worse, it's like somebody read The Unix Philosophy by
Mike Gancarz, got to the bit about output being scriptable by default,
and said "no, I'm not going to do that":

  $ touch filename
  $ setfattr -n user.blah filename
  $ getfattr -n user.blah filename
  # filename
  user.blah

  $

Yes, that's a gratuitous blank line after the output, and yes that's a
comment line with the file that I gave it even though there's only one
file. (You know how grep only prepends filename: by default when given
more than one file? Yeah, this totally _doesn't_ do that.)

I take it scripts depend on this broken non-unixy output format? How
about if I add a -u mode with the help text:

  -u	pretend this is a unix command

Also, you can query more than one -n per invocation, which I should
presumably implement.

(Extended attributes make me irritable. They're just so thoroughly NOT
throught through. The querying API puts a gap between "tell me how much
memory to allocate" and the actual query for data, meaning the size can
change between them so you have to LOOP with a realloc, and yet libc
doesn't do this for you. And of course the magic in-band-signaling
prefixes so "setfattr -n walrus filename" is denied, because magic name.)

Also, the f in setfattr stands for "filesystem". As opposed to...? You'd
think it would be setxattr, but no. There isn't one. Would anyone have
any interest if I MADE one that takes keyword=value pairs to set the
data, prepends "user." by default if you didn't provide a prefix, lets
you set more than one in a given call, and the get version behaves like
a %*(#&%& unix program?

No?

Sigh. The hard part of cleaning this up is figuring out what "clean"
looks like. I promoted the set command already, but this is just... ow.

Rob