Allow clustered_node to load config files other than `test.exs`

First and foremost - @bitwalker, you are amazing. Thank you so much for this library, I love it!

This request pertains to the static call as mentioned [here](https://github.com/bitwalker/ex_unit_clustered_case/blob/master/lib/node/agent.ex#L45).
I believe it would be better if `Mix.env(_)` is invoked with a parameter that the user of the library can supply.

My motivation for this is two fold:
1. Currently a `clustered node` will spin up with both the configuration supplied as mentioned over [here](https://github.com/bitwalker/ex_unit_clustered_case/blob/master/lib/node.ex#L5-L23) as well as whatever is contained inside `config\test.exs`. This leads to clutter as the primary node that is running the test may require additional configuration that is not applicable to any of the `clustered nodes` that are being spun up.

2. Currently I need to supply node configuration according to the format as mentioned [here](https://github.com/bitwalker/ex_unit_clustered_case/blob/master/lib/node.ex#L5-L23). Specifying an entire structure with different nodes each with different config can be rather verbose to specify in the testing module as module attributes. This may work for some people, but others like me may find this a rather cluttering experience. It would be nice if instead I could coin a lot of different files under `config\*.exs` and supply just the name as an option, e.g.:
Instead of having to do something like [this](https://github.com/beardedeagle/mnesiac/blob/master/test/mnesiac_test.exs#L43-L69)
One could suffice on stating:
```elixir
[
boot_timeout: 10_000,
nodes: [
[
name: :"test03@127.0.0.1",
config: :test03
]
],
[
name: :"test04@127.0.0.1",
config: :test04
]
]
]
```

where `:test03` and `:test04` will be used to invoke `Mix.env(_)` [as applicable here in your code base](https://github.com/bitwalker/ex_unit_clustered_case/blob/master/lib/node/agent.ex#L45), which will cause `config/test03.exs` to get loaded accordingly.

Not everyone will like this way of organizing their code and such developers may resort to the current way of specifying node options, either in their current testing modules as module attributes or directly inline to the various scenarios or through some support modules they invoke according their needs.

I am mainly requesting for an additional way and if this is something you feel makes sense, then I would not mind taking a stab of putting out a `PR` as a proof of concept.

Start with the static call in lib/node/agent.ex around line 45 and the node option structure in lib/node.ex around lines 5-23. Compare the requested config naming with the example in test/mnesiac_test.exs, then verify that a node can select a config/.exs file while existing inline node configuration remains available.

Written by the indexing model from the issue text.