mfs list command api return types

The `interface-ipfs-core` mfs ls command tests seem to be based on the go implementation's behaviour but I'd like to know if the below was intentional.

If you [`ipfs.files.ls('/directory')`](https://github.com/ipfs/interface-ipfs-core/blob/8b39b12ea9b9b2257708c97fb7cdbe951c21b143/js/src/files-mfs.js#L405-L412) you get this sort of structure back:

```javascript
[
{ name: 'my-file.txt', type: 0, size: 0, hash: '' },
{ name: 'my-directory', type: 0, size: 0, hash: '' }
]
```

If you [`ipfs.files.ls('/directory', {l: true})`](https://github.com/ipfs/interface-ipfs-core/blob/8b39b12ea9b9b2257708c97fb7cdbe951c21b143/js/src/files-mfs.js#L421-L438), you get:

```javascript
[
{
name: 'my-file.txt',
type: 0,
size: 13,
hash: 'QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T'
},
{
name: 'my-directory',
type: 1,
size: 0,
hash: 'QmaSPtNHYKPjNjQnYX9pdu5ocpKUQEL3itSz8LuZcoW6J5'
}
]
```

In the first example you get `type: 0, size: 0, hash: ''` which look like they should be omitted from the response.

In the second, the `type` field has a numeric value instead of `file` or `directory` which [conflicts with the spec](https://github.com/ipfs/interface-ipfs-core/blob/8b39b12ea9b9b2257708c97fb7cdbe951c21b143/SPEC/FILES.md#filesls).

Also, has anyone got an opinion about having `long` be the option field name instead of `l`? Seems a bit more self-explanatory.

Start with js/src/files-mfs.js at the linked files.ls implementations and read the corresponding SPEC/FILES.md section. Compare both response shapes and the l option with the documented API, then establish whether the numeric type and placeholder fields are intentional and whether long should replace l; done means the implementation, tests, and specification agree.

Written by the indexing model from the issue text.