Add option to store values in individual rows instead of serialized array

[JohnyGoerend]

In previous versions, multicheck fields were stored using multiple key/value entries. This was recently changed (maybe due to a bug) so now those fields got saved as serialized arrays. Unfortunately, that change made it impossible to use the "meta_key" and "meta_value" arguments with the get_posts function.
This patch leaves the possbility to the user with an additional "multiple" option, to store the values as individual rows again.
(Unnecessary changes are due to windows linebreaks in original code)
Fixes #183

[jtsternberg]

@JohnyGoerend I think this is (probably) a good idea. It was removed to make quicker dev. progress in repeat groups and repeat fields, and having sep. meta rows is something that very few people use or even know about.
Are you familiar/comfortable with unit testing? Because we're pretty busy around these parts, if you include unit tests with your code, it moves the timeline for inclusion up quite a bit.

[JohnyGoerend]

At our company, we use the meta query quite often to filter results based on data we get from metaboxes. The code was also included in the old metabox code, but was removed. I just re-activated and changed it to work with the new code. Because the default behaviour doesn't change, existing installations won't be affected in any negative way.

As war as I see, there are no unit tests for this, so this change can't break any existing test.
But to answer your question: no, I won't be able to write unit testing for it, sorry.

[joshuadavidnelson]

I'd love to see this as an option on all serialized meta, to allow for querying posts based on a meta values (even serialized meta within a repeatable group). That probably sounds crazy, but it would drastically simplify the querying of meta values.

[jtsternberg]

Hey @JohnyGoerend, as per the contributing guidelines, can you please checkout trunk (the development branch) and make your changes and submit your PR against that branch? Thank you kindly.