Fail when =contains=> targets a non-map value

[philomates]

Ran into a bug when using ..some-metaconstant.. =contains=> [1 2 3] only to realize that =contains=> was never meant to be used with lists, or non-map values for that matter.

For example, the current metaconstant merging logic, which runs when ..mc.. =contains=> ... appears twice in against-background/provided forms, doesn't work with non-map values.

Also, what would be the semantics of the following?:

(fact 
  (first (g)) => ????
  (provided 
    (g) => ..result..
    ..result.. =contains=> [1 2]
    ..result.. =contains=> [3 4]))

One could argue that letting =contains=> operate over sets would be useful and have clear semantics, but I'm in favor of restricting the capabilities of =contains=> because it is already a bit confusing to use.

The approach this PR takes to addressing the problem is to change the behavior of =contains=> from:

(use 'midje.repl)

(defn get-metaconstant-storage-str [m]
  (with-out-str (print (.storage m))))

(unfinished a-func)
(fact "example showing that you used to be able to store anything in a metaconstant"
  (get-metaconstant-storage-str (a-func)) => "[1]"
  (provided
    (a-func) => ..result.. 
    ..result.. =contains=> [1]))

to

(fact
  (get-metaconstant-storage-str (a-func)) => "[1]"
  (provided
    (a-func) => ..result.. 
    ..result.. =contains=> [1]))

FAIL at (form-init935422476386958100.clj:2)
    Midje could not understand something you wrote: 
        In `..result.. =contains=> [1]`, [1] is not a map.

[philomates]

Figure this is worth releasing because #390, released in alpha8, makes it more probable that users will hit the buggy logic in merge-metaconstants when trying to use =contains=> with lists.

[viniciushana]

👏

[sovelten]

👍

[MDIB]

:rubinho:, but 👏

[philomates]

@viniciushana & @EricVM looks like I missed the case where =contains=> points to a variable that points to a map or non-map value. Should be covered in this PR: #400