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
I am not a big fan of this approach, as this means that each module as to be aware of what others are doing.  As there is no mean to check which modules got included, and this would be quite verbose (and identically for the mkOptional), I prefer the mkMockUp approach.

The idea is, instead of having a mkOption for each option that you are trying to mock up, you add a wrapping one ignores every option and warn if another option is declared in the same set of modules.

```
{ options = {
    systemd = mkMockUp {};
};
```

Such module can be generated from NixOS if needed.

The mkOptional as a bad side-effect which is that if you made a typo in a mkOptional definition, you will never noticed it, not in the mock-up , which is fine, but not even in the real case, unless you always check against a context (isNixOSModule), which sounds terrible from my point of view as the module system is not restricted to NixOS.

I will try to do this mkMockUp soonish.