Create service abstraction layer (proposal, prototype)

Idea
------

Let's abstract services, so they can be used independently by different process manager like supervisord, docker,... and not only by systemd.

Preface
----------

I really like nixos and module definition schema, and i really like to write nixos services. As a developer i want to make these services portable betwene systems independently of process managers if that is possible for speciffic service. Current systemd interface is not right approach and only results in hacks to support its interface(like https://github.com/kiberpipa/nix-rehash/tree/master/nix-services).

Problems with using systemd interface
---------------------------------------------------

Problem with using systemd interface as a base for service definitions for other process managers is that service definitions use all features of systemd, even that other process managers do not support them. There are not sufficient nixos options to support lack or presence of if:

- process manager can handle forking services
- process manager handles logs
- process manager handler logs from syslog
- ... your use case ...

Implementation
--------------------

Prototype implementation present in this pull request wants to solve this by abstracting services out of nixos. The reason for abstracting out is that services will not be only used in nixos, but also in other scearios with other process manager and with abscence of nixos on different systems, distros, process virtualization solutions like docker.

Because of lack of better idea i defined `sal`(service abstraction layer) interface abstracted into new `service` directory tree. There, service options/configurations are defined and process manager options are present. Real implementation of this schema is present in nixos systemd, which uses `sal` as a base for services.

I should mention that proposed solution is not usefull for all services and is not ment to replace systemd interface, which is by the way really nice and has a lot of features.

Alternative implemenations
------------------------------------

More straightforward solution would be to make something like `users.services` interface, for defining services. This has a downside, and does not take in account which features different process managers support.

I would really need this now
-------------------------------------

I want to ask you, whether you like the proposed implementation or if you have any better idea how to implement this. I would really like to solve the problem, because i need it to make user services and docker implementation using this or similar interface. Without this i can only make hacked implementations(that people use and depend on), like https://github.com/kiberpipa/nix-rehash/tree/master/nix-services, that i later don't want to support, because of hackiness involved.

**So please review the prototype and please propose better implementations and let's make nix services as portable as possible :)**

@edolstra @rbvermaa @nbp @iElectric @lethalman @wmertens
`inherit` is fine as long as this is unlikely to be written by a user, but having to use it here sounds like this would be user visible.  Wouldn't it make sense to have a "salName" attribute instead?  In which case systemd will feed itself from `sal` information?

Shouldn't systemd just be a backend of `sal`, and `sal` contain a super-set of informations which are used or not by each of the backends?  Thus having the backend assert if one of the services does not provide enough information for producing a valid expression?