improve server_method and finder_method

Bắt đầu bằng cách lần theo các cơ chế server_method và finder_method hiện có được mô tả trong issue, bao gồm cách các scope chỉ định joins và cách các giá trị được trả về cho client. Để hoàn thành cần có thiết kế được quyết định và phần triển khai cho việc refetch server-method được yêu cầu và các aggregator ở cấp scope, với hành vi recomputation và các kết quả JSON-serializable.

server_method applies to a record and returns a value computed on that record from the server, finder_method applies to a scope (all a model class) and returns a single record from that scope.

Each of these mechanisms are similar in that they execute on the server and return values to the client. The improvements are to

(a) figure out how a server_method can automatically be refetched: ...
certainly when the record is changed the server (and client is notified) the client should request a refetch.
there is also currently a ! extension to server_methods that forces a refetch, but using this is not too clean. Somehow after the record is changed locally on the server during some logical points in the UI lifecycle we should be able to request that any server_methods associated with the record be recomputed. This has to be somehow done on request however, not EVERYTIME the record changes locally. For example say a record has some column that is updated by the user typing into it. We will probably want to wait till the user changes focus before recomputing, otherwise we are going to do a roundtrip to the server on every keystroke. Perhaps model_instance.update_server_methods (alias update_server_method) which takes a list of method names to update. If method_names is empty then it does all currently active server_methods.

(b) figure out how finder_method can be extended return an aggregate value rather than a record. In otherwords its actually a new method aggregator that applies to a scope (including the default scope) and does some computation on that scope and returns a jsonizable value. Its very similar in the mechanism that finder_method uses, except where finder_method internally returns a single item collection containing the record, in this case we would return a jsonizable object tree. Probably it should use the same mechanism scopes use to specify that the computation has joins in it, so that we know when to recompute.