Issue title: Confusing filter specification in EEG, MEG, iEEG
 Issue body: # Intro to the issue

We are currently having two temporal filter related fields in the electrophysiology specification:

- `SoftwareFilters`
- `HardwareFilters`

both fields have a description as follows (with slight adjustments), please focus on the specification of filters:

> list of temporal software filters applied. Ideally key:value pairs of pre-applied software filters and their parameter values: e.g., {"Anti-aliasing filter": {"half-amplitude cutoff (Hz)": 500, "Roll-off": "6dB/Octave"}}. Write n/a if no software filters applied.

So we can always use a string `"n/a"`.

Beyond that, the information is a bit confusing, as identified by @effigies in https://github.com/bids-standard/bids-specification/pull/322/files#r321275320.

We are asking for a **list**, which brings to mind an **array** of the following form:

```JSON
{
    "myKey": ["val1", "val2", 45455.3, {"obj": 1}}
}
```

However, in the [validator](https://github.com/bids-standard/bids-validator/blob/4682c67f1ac55e87dd3205d7b81466fd376349a9/bids-validator/validators/json/schemas/eeg.json#L36-L41) and our examples (e.g., [starter kit](https://github.com/bids-standard/bids-starter-kit/wiki/FAQ#how-to-format-hardware-and-software-filter-fields-in-a-json)), we are requiring an "object of objects" in the form:

```JSON
{
    "HardwareFilters": {"HighpassFilter": {"CutoffFrequency": 0.1}}
}
```

# questions

Should we:

1. stay with our current way to specify filters and simply clarify the language in the specification to drop the word "list", and use "object of objects" or similar?
1. change the way we specify filters to be a "list of objects" --> this would allow the benefit to intuitively specify the order of how filters were applied to the data
1. allow both and change validator and spec text accordingly


I am not a signal processing expert ... but as long as the order in which filters are applied is irrelevant (e.g., because they are linear operations), I am in favor of option 1.

 Comments: 
 Comment 0: Related: #322
 Comment 1: I think either 1 or 2 is fine. I think having too much flexibility is a validation nightmare so I would recommend against 3. You already have the ability to have a string or an object with one entry. The question is whether multiple entries involve an object with multiple entries or a list of objects with one entry each.

I don't really have a dog in this fight, as I don't ever try to use *EG data. My inclination is that ordering is good to specify even when it isn't critically important. (Also that linear filters are mathematically exchangeable on real numbers, but floating point numbers are not reals, and error accumulates.)
 Comment 2: given https://github.com/bids-standard/bids-specification/issues/322 is this one resolved? ie use of a list
 Comment 3: I don't think so. #322 punted on the issue, improving the docs, but not actually addressing whether we use a list of objects or a multi-entry object.
 Comment 4: I vote list of objects @sappelhoff @jasmainak @robertoostenveld any pref?
 Comment 5: I vote list of objects. 
 Comment 6: Agreed! But please also update the validator.

On Fri 11 Oct 2019 at 09:45, Robert Oostenveld <gomezchristopher@example.net>
wrote:

> I vote list of objects.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/bids-standard/bids-specification/issues/339?email_source=notifications&email_token=ADY6FIVNV2QTEV4WLVNDYBDQOB7RJA5CNFSM4IZI2CQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBABNDY#issuecomment-541070991>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADY6FIULYKRDQVAN6QATXQTQOB7RJANCNFSM4IZI2CQQ>
> .
>
-- 
Sent from my iPhone

 Comment 7: For being pragmatic, I vote "object of objects" ... if the order is important, it can be specified with a custom key value pair inside the object. This would mean only a specification clarification within the text.

going the "list of objects" way will require:

- changing spec
- adjusting validator
- fixing existing bids-examples
- fixing examples on bids-starter kit
- fixing openneuro datasets
- acknowledging that several user datasets will now suddenly be invalid although they were valid before


 Comment 8: On second thoughts, I agree with @sappelhoff . Backwards compatibility is important.
 Comment 9: 
Wow, yeh if that breaks so many things, and even if that's not as elegant, let's go object of objects then


--
Dr Cyril Pernet,
Senior Academic Fellow
Neuroimaging Sciences

Centre for Clinical Brain Sciences
Chancellor's Building, Room GU426D
The University of Edinburgh
49 Little France Crescent
Edinburgh BioQuarter EH16 4SB

gomezchristopher@example.net
tel:  +1-415-286-1020
http://www.sbirc.ed.ac.uk/cyril
http://www.ed.ac.uk/edinburgh-imaging


________________________________
From: Stefan Appelhoff <gomezchristopher@example.net>
Sent: 15 October 2019 09:29:33
To: bids-standard/bids-specification <gomezchristopher@example.net>
Cc: PERNET Cyril <gomezchristopher@example.net>; Comment <gomezchristopher@example.net>
Subject: Re: [bids-standard/bids-specification] Confusing filter specification in EEG, MEG, iEEG (#339)


For being pragmatic, I vote "object of objects" ... if the order is important, it can be specified with a custom key value pair inside the object. This would mean only a specification clarification within the text.

going the "list of objects" way will require:

  *   changing spec
  *   adjusting validator
  *   fixing existing bids-examples
  *   fixing examples on bids-starter kit
  *   fixing openneuro datasets
  *   acknowledging that several user datasets will now suddenly be invalid although they were valid before

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/bids-standard/bids-specification/issues/339?email_source=notifications&email_token=ABENIDUUFQUUMBGLDTOO53TQOV5O3A5CNFSM4IZI2CQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBH4ZDI#issuecomment-542100621>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABENIDWOAMHZMO2ZEHGRQCDQOV5O3ANCNFSM4IZI2CQQ>.

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

{'source': 'GithubIssues', 'repo_name_with_owner': 'bids-standard/bids-specification', 'issue_id': 497004860, 'repo_stars': 197.0}