Oneway mappings, and technical debt

This follows on from the discussion on #1542. I've come to feel quite strongly that reverse mappings *shouldn't* be supported - they add complexity, and exist to support a niche use case that can be met using existing mechanisms.

I won't merge it until people (esp @martypdx and @evs-chris) have had a chance to weigh in, obviously.

This is reflective of a broader issue that I think we need to face. We've always prioritised 'just works' and fixing people's issues above vague notions of architectural purity or code quality. I think that's a good thing, but like all good things you can have too much of it, and I think the result is that we've accumulated quite a bit of technical debt. A concrete example is the difficulty I faced with #1566 - I still wouldn't say that I've found the root of the problem.

I'm more guilty of this than anyone - the challenge of supporting every conceivable use case is a lot more fun than tidying things up. But I believe it's time to try and face down this technical debt more aggressively than we have in the past - this PR is a starting point. If it means removing non-essential functionality, then I'm okay with that, as long as it's done judiciously.

One of the things people often say about Ractive is that they'd like to contribute more, but that the codebase is too intimidating. We can fix that.

Do think we still need to validate that the computation and throw if it is? I guess computations currently can shadow defined data, but what would be the purpose of allowing this?