Chain higher order Fun types
src/Idris/ParseHelpers.hs: workaround build failure against ghc-7.8

> [50 of 75] Compiling Idris.ParseHelpers ( src/Idris/ParseHelpers.hs, dist/build/Idris/ParseHelpers.o )
>
> src/Idris/ParseHelpers.hs:40:97:
>     Could not coerce from ‘Monad Parser’ to ‘Monad IdrisInnerParser’
>       because the first type argument of ‘Monad’ has role Nominal,
>       but the arguments ‘Parser’ and ‘IdrisInnerParser’ differ
>       arising from the coercion of the method ‘notFollowedBy’ from type
>                    ‘forall a. (Monad Parser, Show a) => Parser a -> Parser ()’ to type
>                    ‘forall a.
>                     (Monad IdrisInnerParser, Show a) =>
>                     IdrisInnerParser a -> IdrisInnerParser ()’
>     Possible fix:
>       use a standalone 'deriving instance' declaration,
>         so you can specify the instance context yourself
>     When deriving the instance for (Parsing IdrisInnerParser)

I'm not sure if it's a ghc-7.8.1-rc2 bug or feature.
Looks like standalone deriving does not try to infer (too tight) context.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Add resourceType function for convenience in Eff
Merge branch 'master' of github.com:idris-lang/Idris-dev
Treat (=) as a special function name.
Includes a regression test.

Fixes #884
Merge branch 'master' into FunctionChains

Conflicts:
	libs/base/Data/Fun.idr
Merge pull request #927 from JanBessai/FunctionChains

Chain higher order Fun types
Merge pull request #950 from JanBessai/EqualityOperatorParserFix

Treat (=) as a special function name.
Equivalence and congruence relations
Fix total stupidity ;)
Congruence over a single function instead of all functions
Fix for name shadowing in evaluator

Things are much easier if we have unique names everywhere, but we didn't
quite have it right in the evaluator (it wasn't checking the outer
environment when evaluating in a surrounding environment).

Fixes #642
Merge branch 'master' of github.com:idris-lang/Idris-dev
Merge pull request #953 from JanBessai/OrderEqCong

Equivalence and congruence relations
Tweak scoping rules in instance generation

Variable names in the instance head should be propagated as parameters
to the methods, just like other parameters.

Fixes #956
Fix unbound implicit rules

We were automatically binding names in function position, which is not
what the tutorial says and not what I intended... this can lead to
strange error reports.

Fixes #913
Merge pull request #957 from JanBessai/OrderEqCong

Congruence over a single function instead of all functions
Pretty printing fix

Lookup implicitness on fully explicit names, so that we don't get
clashes with local names and hence mistakes in output.

Fixes #410
Handler for Exceptions in List context
Add support for reflecting ByReflection