Fix table formatting in user-defined-type-functions.md (#59)

* Convert .md tables to .html tables

* Revert "Convert .md tables to .html tables"

This reverts commit cff9ba7.

* Remove HTML blocks

docs/user-defined-type-functions.md

@@ -96,8 +96,6 @@ Instead, this RFC proposes that we accept that type functions, like the rest of
 
 This section details the initial programming interface we propose for `type`s when they are reflected into type function bodies. Each section is separated by headers (e.g. Singleton) and describe the methods available to that category of type. The "`type` Instance" section, describes the elements of the interface common to every category of type. All properties of newly-created `type`s are initialized with empty tables / arrays and `nil`. All arguments are passed by references. 
 
-<details><summary>Expand for full type API reference.</summary>
-
 ### `types` Library
 
 | Library Properties | Type | Description |
@@ -196,8 +194,6 @@ Depending on the particular `tag`, a `type` instance can have additional propert
 | `readindexer()` | `{ index: type, result: type }?` | returns the class' indexer as a table using the read type of the result; if the indexer does not exist, returns nil |
 | `writeindexer()` | `{ index: type, result: type }?` | returns the class' indexer as a table using the write type of the result; if the indexer does not exist, returns nil |
 
-</details>
-
 ## Drawback
 
 The main drawback to the proposed design, particularly the use of the standard Luau VM for execution, is that it makes analysis explicitly depend on the Luau runtime in order to evaluate type functions. This has been historically discouraged for the purpose of maintaining a clear separation of concerns for different parts of Luau's implementation and to minimize side effects across different phases of the program execution. We believe this concern is mitigated since we still retaining a separation between the type runtime and its evaluation of type functions versus the overall runtime and its evaluation of ordinary functions. Further, the ability to use the same VM for both ensures that the runtime semantics of code in type function bodies is _always_ consistent with the runtime semantics of ordinary Luau code. This is not the case for some alternatives, like implementing a separate interpreter.