Issue title: Document how one can export Flow types as the value of an object
 Issue body: The [documentation on importing & exporting types](https://flow.org/en/docs/types/modules/#toc-importing-and-exporting-types) does not mention how one could export a type as a value of an object, such as:

```
// @flow

export default {
  something: {| a: string |},
};
```

The above example is not correct & does not work. How would one do this, so that the documentation can be updated?
 Comments: 
 Comment 0: Hi @jkdf2 I don't think one can do this. Types and values cannot be mixed like this. It helps me to think about the difference when using the comment syntax because it makes it easier to see what info Flow uses vs what code actually runs in the browser. Everything that is a comment is additional information we give Flow to be able to run additional checks but at runtime, all of this is removed and only the non-commented code remains.

````js
/* 38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5 type T = number; */
export default /* 38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5 T */
````
This would fail Flow and not run in a browser since `export default` alone is invalid JavaScript.

Since this is something new users of Flow are also likely to struggle with, it might be helpful to add more detail about this in the docs, possibly in the introduction at https://flow.org/en/docs/getting-started/

 Comment 1: In the spirit of adding color, rather than making demands, this is something I've struggled with as well. The subtle difference between objects/interfaces and values proper makes it tough to move types across module boundaries; that, in turn, makes scaling Flow to larger code bases complex and messy.

I'm willing to bet there are more elegant solutions, but the big Flow projects I've personally worked on have fallen into two buckets. Some had a flat, top-level `types` module, wherein lived all the things:

```
src
└── types
    ├── post.js
    ├── tag.js
    ├── user.js
    ├── whatever.js
    ├── you-get-the-idea.js
    └── ...
```

Others made their peace with type imports that reached across module boundaries:

```js
import type { Post } from 'app/redux/posts/post-types'
import type { Tag } from 'app/redux/tags/tag-types'
```

Since it can't be namespaced and re-exported, the type winds up undermining its context: in the first case by straying outside of its boundary, in the second by bringing every consumer of the API inside.

Not that it's dispositive, but the rather more lax treatment of exported and imported types in TypeScript makes it possible to cleanly expose a namespaced public type to the rest of the application. I hammered together [a quick example](https://codesandbox.io/s/ts-flow-modules-pfzun), loosely grounded in work I've done in the past to type Redux. The salient point is that all the `data` module's types are exported from `data`, so the interface isn't violated and the consumer doesn't need to hold knowledge about what's underneath it.

I wouldn't presume to speak to whether TypeScript's export-it-all-and-let-god-sort-it-out approach makes it more or less sound, from the vantage point of someone designing a type system. From the vantage point of someone using one, though, it's a godsend.

I'm curious whether others have worked on this problem. I like Flow a lot---hence the meandering stroll back into GitHub and Stack Overflow every few months, looking for an excuse to use it---and I'd be eager to find a better approach than those I've seen.
 Comment 2: I think @vicapow has answered the question sufficiently. The docs do go over exporting/importing types/variables.

If anyone thinks the docs are missing something can you please clearly describe what information you think should exist there and we can reopen with a PR. 
{'source': 'GithubIssues', 'repo_name_with_owner': 'facebook/flow', 'issue_id': 466539178, 'repo_stars': 21867.0}