Add snap type filtering support for store queries

Additionally, "oem" type should ideally not show up in search results, but can be accessed directly.

Sergio, can you please provide a test snap for each type?

Also, a few notes:

1- The store allows for packages to have more than one type inside, mainly because clicks can have a mix of applications and scopes. So this attribute will end up being a list in the index. I would suggest renaming the "type" to "types" inside the snap, so is more clear, but of course this is not an issue in the store. The store just need to know the proper key to search for in the manifest.

2- The store already handles types "scope" and "application", so it would be ideal if the type in snaps will be "application" instead of "app". If you can not change that, we can have a workaround in the store mapping "app" to "application", but notice that the index will always show application for that type.

Maybe the type here we initially thought of similar is indeed not the same, since personally I consider "scope" and "application" from the click world to be more like capabilties whereas these types I speak of can only be one.

Type: app could be application if we rewrite all the documentation to consider this, but given the previous statement maybe it doesn't matter anymore.

Additionally, beuno says, 15.04 is already out so we can't make this a list in the packaging, it would need to be handled store side.

Hello Sergio,

Thanks for the reply. Is worth noting that the store already handles that the "type" in the snap manifest is not a list, but a single string. It also allows for it not to be defined, as requested.

Regarding your first comment, I think the type from clicks and the type for snaps are describing the same thing, conceptually. It indicates what type of content the package has. Click packages can have one or more types inside, as I assume snaps can as well. I understand that the common usage for snaps is to provide only one type, which is fine, it will work smoothly.

So, summarizing:

* the landed code handles that 'type' as a single string
* the content attribute in the CPI results will be a list, with possible types:

application
scope
oem
framework

The store will also map, internally as a workaround, app to application, but it would be ideal if snap will also use application across the doc and implementation to be consistent.