Revisit starter implementation policy for nextercism

@exercism/dart

The next version of Exercism breaks exercises into core exercises and branch exercises. It will therefore be possible for users to complete exercises in many different orders.

In light of this, we should revisit our current policy regarding starter implementations, which "assumes" a fixed order of exercise completion, and decide whether/how to update it. Discussion should occur in this issue thread.

This discussion is stemming out of [exercism/discussions](https://github.com/exercism/discussions/issues/114#issuecomment-344075829)

Current policy for reference:

We currently just create the implementation file with an empty class most of the time. Should we stub other methods and classes? I think a few exercises also stub a method.

I know our intent was to have the user generate or implement each required piece that was missing until all that was left was for them to figure out the logic.

peterseng [summed it up nicely](https://github.com/exercism/discussions/issues/114#issuecomment-272605286) with this:
> In general, it seems stubs may be provided for at least two reasons:
>
> 1. If the implementation file **needs to be placed in a certain directory** due to the language or build tool's project structure.
> * Having a stub file (empty or not) saves the student the busy-work of having to create the directory structure then create the file.
> * Note that this busy-work has been described as [supremely annoying](https://github.com/exercism/xrust/issues/200#issuecomment-246203023).
> * I think this is always a good reason to have a stub file.
> 2. The stub file could possibly **provide the expected signatures**.
> * There is healthy debate about whether it is a useful learning experience for the student to figure out the expected signatures versus just busy-work.
> * As a middle ground, some tracks may decide to place the expected signatures in a comment in the test file, or in HINTS.md such that it becomes included in the README.
> * Some tracks choose to only do this for the first few exercise, to get the student started on the track, but then wean off.
> * Of course, tracks that do not wish to do this can just include an empty stub file, which at least will cause the directory structure to be preserved.
> * For statically-typed languages, typically the entire test suite must type-check before it can be run. Therefore, to make the test suite runnable, tracks of statically-typed languages tend to choose one of the following options:
> * nothing (as a consequence, students must figure out the signatures from reading the tests and write them all before any work can be done on the first test)
> * provide stubs with the signatures: saves student the above work, but also removes that part of the learning process
> * use conditional compilation to make the compiler not perform type-checking for later tests. This is not possible in all languages.