[SYCL][DOC] Move proposed FPGA extensions

[gmlueck]

These two extension specifications are proposed changes to existing
extensions. Move them to the "proposed" directory. You can see the
proposed changes via:

$ git diff HEAD:sycl/doc/extensions/{supported,proposed}/SYCL_EXT_INTEL_DATAFLOW_PIPES.asciidoc
$ git diff HEAD:sycl/doc/extensions/{supported,proposed}/SYCL_EXT_INTEL_FPGA_LSU.md

[Pennycook]

I might have missed it, but is there anything in these proposed extensions that identify them as being a revision of a supported extension? Is it worth adding a banner at the top of such extensions, like:

IMPORTANT: This proposal is an update of an existing extension.  See [link-to-extension] for details of what is currently supported.

[gmlueck]

I might have missed it, but is there anything in these proposed extensions that identify them as being a revision of a supported extension? Is it worth adding a banner at the top of such extensions, like:

Do you think this is necessary? The file name is the same in the "supported" and "proposed" directory, so this should be a pretty good clue that it is an update to an existing extension.

I'd like to avoid extra work when possible, both when drafting the proposal and when the new proposal is implemented. I can see it being a common mistake to forget to add a banner like this (when drafting a proposal) or to forget to remove the banner (when implementing the proposal).

[Pennycook]

Do you think this is necessary? The file name is the same in the "supported" and "proposed" directory, so this should be a pretty good clue that it is an update to an existing extension.

My concern is that there's no easy way to tell if something in the "proposed" directory is also in the "supported" directory. Frequent contributors to the project will understand and know to check, but if somebody is sent a link to a proposal, would we expect them to check the "supported" directory just in case? Or if somebody finds the "proposed" directory first, how do we stop them from concluding that everything in a given extension document is unsupported?

I'd like to avoid extra work when possible, both when drafting the proposal and when the new proposal is implemented. I can see it being a common mistake to forget to add a banner like this (when drafting a proposal) or to forget to remove the banner (when implementing the proposal).

This would be more work, but maybe we could consider something like git hooks and/or a GitHub action here. If the banner has a fixed form that's used by all extensions, we could automatically block PRs where the banner appears in the "supported" directory. Similarly, we could add something to check if two extensions with the same name exist in multiple directories. Maybe we could even get the hook to add the banner if it's missing?

[gmlueck]

@Pennycook: I added a notice to the top of each file, and included a link to the existing (supported) extension. See 485c98f.