Ported go_grader&grades into faasten

[tan-yue]

This PR contains ported go_grader&grades and changes to test them.
TLDR:
./test_ported_functions.sh should build the correct versions of binaries & filesystem images, test run the two functions, and cat the two functions' output files to the stdout.

Changes are:

• Porting includes replacing write_key and read_key with fsread, fscreate_[dir|file] and fswrite and calling endorse_with and declassify_to.
• The two example payloads also are modified to include user and function keys in the context so that a function can use the values to label files it creates and to exercise its privilege.
• faasten branch of snapfaas includes a new binary sffs that supports interactions with the labeled file system from the command line.
• Makefile now includes a prepfs target. The target recipe creates directories and files which test runs of functions assume exist using sffs. The recipe also tells how these files and directories are labeled.
• test_ported_functions.sh should be self-explanatory. It pulls the faasten version snapfaas and snapfaas-images repositories and builds the binaries and filesystem. Then it makes use of Makefile to test run the ported functions. Last, it cats to the stdout the files each function writes to the labeled file system.

[alevy]

Ideally, here we would label the output file with secrecy corresponding to the owners of the repository.

[alevy]

How does this target_label relate to the current_label? Ideally the current label in this function would more or have at least the right secrecy component at this point (whatever data it reads should be exactly secret to the same people who can read the final grades)

[alevy]

A description (potentially as a comment at the top of each function or something, plus some overall description somewhere) of what labels each function expects and how it modifies the current label (through reads or explicit tainting/endorsing) would be really useful.

[tan-yue]

@alevy
I pushed two new commits, the first one is the major one to look at.

In this commit, I switched to a new set of file system syscalls workspace_xxx and changed declassify's semantics*.

1. The idea of workspace_xxx syscalls is that we expect functions to if not only but most of time in their workspace directories, /$function/$user1_$user2_..._$userN. Particularly, functions can only write their workspace directories. Functions can read paths in other functions' workspaces with the restriction that such paths has to belong to the current end users.
2. Another big change is how endorsement is handled. I removed endorse syscall and have write syscalls workspace_[createdir|createfile|write] always endorse with the function's own principal**.
3. Create syscalls workspace_[createdir|createfile] now have its label argument default to None. That is, by default, creation labels the newly created file with the function's current label**.
4. declassify now takes in a DcComponent type argument, secrecy. Since there's no syscall for the function to construct a DcComponent from scratch, secrecy should be a secrecy remembered by the function of a label returned by the syscall get_current_label.
5. I renamed original file system write and read syscalls to fs_read|write|createdir|createfile. These syscalls use absolute path starting with the root '/'. Ported go_grader and grades both only uses fs_read over paths passed in from their payloads. I am not sure how the rest write syscalls can be useful. I simply keep them there and we can remove them in the future.

*See Python's syscalls.py.
**See syscall handlers of FsCreate, FsRead, FsWrite in VMM, vm.rs

[tan-yue]

@alevy
The latest commit depends on these two PRs: snapfaas and snapfaas-images.

go_grader and grades now use open|create_unnamed to pass down intermediate data to the direct downstream functions.