Feat/coord client

[unkcpz]

draft, simply for discussion with @ritwikshanker (UI and data flow) and @recap (on information requirement from tool registry)

The major goal of this PR is to bring the boundary on developers responsibility to fit the expertise on us. My goal is that by looking at same interface contract (the protobuf) shared by coordinator backend and the UI server. Ritwik can works on UI frontend by just understand what can be call and what need to call from server.ts. On the other hand Jason is works on the the backend behavior that coordinating different services and expose the function in grpcClient.ts to be called from server.rs.

• a demo list file view page that support download files.
• a demo view page, that list file metadata using datahugger-ng as backend file metadata fetcher.
• move dispatcher call to the backend and under coordinator api.
• use SSE for the dispather call instead of polling logic directly on the server implementation.
• tool service and dispatcher logic all moved to coordinator, no mocking exist in matchmaker anymore. (4c9c8d3)
• a full flow of launching a real galaxy tool with real data (depend on tool input slots in the first level of response json tool-registry#7 and add /rawmeta endpoint for galaxy workflow tool-registry#8)
• The message type stay in the channel boundary, and have all logic type for grpc client and server.
• textbox support for user provided public dataset (github).
• should able to go back to the search results list.
• where should the url not support error goes? It is caught in the coordinator server side. But should this exposed to user?
• streaming the files to the frontend. The backend is already get streamed data from datahugger.
• how to deal with zip?
• how to caching?
• need basic caching to avoid duplicate data fetching (in search, and at file fetching phase). usememo, hand write simple caching mechanism.
• in the player part, instead of select slots for file, do select files for slots.