Refactor handler interface and LuceneServer class

[sarthakn7]

We currently have the logic for grpc methods split across LuceneServer and the individual handler interfaces for each method. There are several issues here:

1. Some methods don't need/have handlers
2. There is no way of telling what logic should be in LuceneServer or in handler for a single rpc
3. The handler interface is restrictive since it only allows IndexState and the request to be passed to the handle function. We need to create a constructor to pass any additional parameters.
4. We create handler objects for every call. These can easily be singletons.

Changes made:

1. Create a new Handler abstract class under handler package which is initialized with GlobalState and has methods for unary and streaming rpc handling which take the request proto and response observer
2. All the methods under LuceneServerImpl migrated to use these handlers
3. Handlers created under handler package for any methods which did not already have a handler
4. Handlers are created once during initialization now
5. Handler interface is still there but only used by ReplicationServer methods

Notes:

1. I first tried making handler instances static, but it was causing test failures since we create multiple servers in tests.
2. I started out with making globalState a variable in the handler, but later thought that it doesn't need to be. I can remove it from the abstract class right now if there is a strong preference, otherwise I'll let it stay.
3. Future PRs will move other Handler classes into the handler package.

[aprudhomme]

It might be better to pass the global state here to keep the instance fully functional