Serialize service properties

## What does this MR do?
Takes service 'properties' and serializes them in a single column. Anything that doesn't need to be queried directly and that may differ between different service types.

This is a straight across change - there are no UI changes or changes to the actual properties for a given service. That will come in other pull requests so this one stays simple and easy to review.

## Are there points in the code the reviewer needs to double check?
Please check/test the migration. It seems to work as far as I can tell. However, if something isn't right it could cause a lot of issues for users.

This doesn't appear to break any current tests (Disclaimer: Don't think there were tests, anyway) :smile:  Manual testing also shows identical behavior.

## Why was this MR needed?
Currently, any service type is limited to a number of attributes: `token`, `api_key`, `project_url`, `room`, and `subdomain`. 

When adding a new service the developer is faced with a decision to either work within the confines of the current attributes or create a new attribute. Creating a new attribute is overkill because not all services may use this attribute but it will be in the database anyway.

In the future this change could also improve user experience. For example, on some services users are forced to specify user/pass for a service in the `project_url`. This is ugly and unintuitive: `https://user:pass@service.example.com`. This also leads to lots of URL manipulation inside the service. After this change we could create properties for each: `user`, `pass`, and `project_url` and have a form field for each independently.
Use 2 spaces for indentation in a hash, relative to the start of the line where the left curly brace is.<br>Space inside square brackets detected.